• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

ATOT Nef Thread?

Page 93 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Status
Not open for further replies.
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.
 
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:
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
Status
Not open for further replies.
Back
Top