Sharepoint large document library - best practise

Question

I work for a company that creates software that interfaces with Sharepoint through web services (this is due to the backwards compatibility needed for Sharepoint 2007). How we setup sharepoint to store files from the third party software is to create a handful of document libraries and allow the software to upload to these libraries from various points of entry in the software.

We have been getting some concerns from our clients when some of these libraries are reaching the tens of thousands of documents. What i'm curious about is what would be the best practice used in this case to store documents?

Here are some of the solutions being considered:

• Creating folders within the library by date to minimize the amount of documents within the library. (Pros? Cons?)
• Creating indexes and filtered views on meta data. (Pros? Cons?) -- This doesn't necessarily fix the massive amounts of documents within the 1 library but if this is an option i can present to my clients then i will.
• Creating a Document Center or Records Center - (Pros? Cons?) I don't know much about either of these.

Thanks in advance!

Answer 1

The current supported boundary is 30 million items in a library, it takes some careful planning and archetecting to make that scalable and usable. I'd have to go back and see what the boundary was for 2007.

Folders is definitely the way to go, you want to create it in such a way that no particular view returns more than 5000 items and all necessary fields are indexed. This will really depend on volume though. Perhaps customers want it stored in client folders, then year folders. Your complaints and questions from clients might give you different options on how you want to build in the folder structure, but that is where you need to head.

You could even segment this further by introducing a rollover, in that at some customer defined point, a new library is provisioned for the new (calendar/fiscal) year. This gives a logical separation of data based on their timing metrics, which then makes it easier to dispose of data at defined retention points.

This also requires a robust search infrastructure if you are going to that upward bound in thresh hold limits.