ATOT Nef Thread?

[eldorado99]

ned

 

[MotF Bane]

I think one database starting at ten times the size, but a fixed size, would be better than a smaller database that will grow at a linear rate forever.

 

[IndyColtsFan]

Starting at 8000 entries and growing at a rate of 1000/year. Accordingly, roughly 1000/yr would go dead, but unless properly deleted, which they've never done before, they'll stick in there.

As for the size of an entry, they could a) use the reference number and look up from a different db and keep just the quantities in this one, or b) use the reference number and look up from an online db, or c) load all the details and data into this db. If a or b, a couple Kb per entry? If c, 10-20 Kb?

So "huge" is a relative term, but there is no limit to how far it will grow.

In one of my systems, we image and store roughly 500K documents per year, complete with tagged metadata. :awe:

 

[eldorado99]

teff

 

[IndyColtsFan]

Create an image file on another HDD.
Restore this to your SSD.
Realign the partition using a free utility.

What's a good (hopefully free) imaging tool these days?

 

[MotF Bane]

To further complicate it... the items come in various sizes, and people can purchase less than a full unit.

 

[IndyColtsFan]

To further complicate it... the items come in various sizes, and people can purchase less than a full unit.

Sounds like you need to come up with a labeling standard and encode that in the bar code.

 

[MotF Bane]

In one of my systems, we image and store roughly 500K documents per year, complete with tagged metadata. :awe:

That's, uh, colossal.

Our "servers" are a few Dell workstations sitting on a counter in an office. Our total personnel number about one hundred. Major difference of scale.

 

[MotF Bane]

Sounds like you need to come up with a labeling standard and encode that in the bar code.

Yep, and then do partial checkouts... instead of purchasing by a full unit, you can enter the quantity taken as a decimal, a partial unit.

But I'm not the one making the decision.

 

[IndyColtsFan]

That's, uh, colossal.

Our "servers" are a few Dell workstations sitting on a counter in an office. Our total personnel number about one hundred. Major difference of scale.

Even still, our DB is "only" 200 GB in size. One of my projects this year is to start splitting that up. SQL can handle larger DBs and so can Sharepoint, but they don't recommend going much above that.

Since we're due for a major upgrade (both from a Sharepoint perspective and a KnowledgeLake {imaging software} perspective), I'm thinking about just waiting for the upgrade and then just doing a straight cutover. The current DB will become an archival system and the new DB will store docs going forward.

 

[MotF Bane]

Nef.

 

[MotF Bane]

Even still, our DB is "only" 200 GB in size. One of my projects this year is to start splitting that up. SQL can handle larger DBs and so can Sharepoint, but they don't recommend going much above that.

Since we're due for a major upgrade (both from a Sharepoint perspective and a KnowledgeLake {imaging software} perspective), I'm thinking about just waiting for the upgrade and then just doing a straight cutover. The current DB will become an archival system and the new DB will store docs going forward.

A good plan.

 

[MotF Bane]

Oh damn, tracking by location... D:

 

[MotF Bane]

I don't understand why we're supposed to know every item in every room, instead of just the rooms of our direct responsibility.

 

[IndyColtsFan]

A good plan.

There was a Sharepoint thread a couple months ago where an agitated user "threatened" his Sharepoint admins with dumping 11,000 documents into a document library. I laughed at the guy and pointed out that I have a document library that is probably north of 1.5 million documents.

 

[IndyColtsFan]

Oh damn, tracking by location... D:

How are you supposed to know if JimBob the lab tech takes some chemical from one room to the next? Are you supposed to conduct physical inventories every month?

 

[MotF Bane]

Oh right, can't change inventory program, stuck with theirs.

 

[Rubycon]

How are you supposed to know if JimBob the lab tech takes some chemical from one room to the next? Are you supposed to conduct physical inventories every month?

Use the right system in the first place?
http://limsource.com/home.html



Paragon used to be free for alignment.

 

[MotF Bane]

There was a Sharepoint thread a couple months ago where an agitated user "threatened" his Sharepoint admins with dumping 11,000 documents into a document library. I laughed at the guy and pointed out that I have a document library that is probably north of 1.5 million documents.

Hahaha.

 

[MotF Bane]

How are you supposed to know if JimBob the lab tech takes some chemical from one room to the next? Are you supposed to conduct physical inventories every month?

We can't. They won't be bothered to tell us, or to track their own inventory, and we wouldn't be allowed to access their rooms to take physical inventories. The only rooms we have direct responsibility over we control the keys to, and therefore they can only get chemicals by passing through here - so it can all be scanned and accounted for at that point.

 

[MotF Bane]

This sudden inventory push will probably last until students return, then fall away as everything gets busy again.

 

[MotF Bane]

Nef.

 

[IndyColtsFan]

Use the right system in the first place?
http://limsource.com/home.html



Paragon used to be free for alignment.

Ah yes, LIMS. I've not seen or heard of that product in many years.

 

[MotF Bane]

Nerf.

 

[Rubycon]

Ah yes, LIMS. I've not seen or heard of that product in many years.

Last time I saw it in use they have a 35,000 sq ft room full of oracle servers for it. Supposedly if a user looks at their screen cross-eyed an auditor can find out years later.