As I look back at the history of SharePoint, one of the primary features that made it so popular is the ability to store and work with any type of files. This is GREAT from a user standpoint, but that capability requires that SharePoint work with those files as a BLOB (Black box of bits) when it stores them. Second order issue for that then becomes that differencing versions of files becomes impractical and thus you end up with a copy of each version of a file. If you’ve got a lot of active people working on documents, and you’re tracking versions – you end up having two basic options. Limit how many versions of those files you will keep (putting a limit on how useful versioning is in the first place – not something your users will like), or throw LOTS of database space at your implementation (something that could have your DBA coming after you with a brick.)
Well, with the 2007 generation of SharePoint, the product team introduced a feature deep in the technical documentation to allow remote blob stores. This was something they were working very hard on to get to the right level of performance, ease, and API maturity so they kept it a bit low key. But with the 2010 generation of SharePoint that we’re testing today, that capability is coming to the forefront for implementations that have very large numbers of files, or even organizations that already have mature file stores, and would like SharePoint to provide even easier integration.
If you’re in either of these situations, or just interested in catching up with something that’s been around for a bit, but hasn’t been really in the spotlight, I’d highly recommend taking a look at the capabilities.
http://blogs.msdn.com/opal/archive/2009/12/07/sharepoint-2010-beta-with-filestream-rbs-provider.aspx
