Storage is one of the most prickly topics related to document management systems. Not all of them have been designed in the most optimal way to handle large quantities of documentation.
The way in which SQL Server stores its content:
As you’ll know, Microsoft uses SQL Server as its database manager (SGBD). Most content and documents that we store in SharePoint are saved in this SGBD as a “BLOB”, a type that saves large-size binary data, and which can be accessed using indices. Since it’s not used as references for content (content itself is stored in the database), access to the data is fairly taxing for the system. BLOB-type SQL databases make up 95% of the size of Sharepoint and those, for sure, do tend to have a fairly large size.
The increase in use of large-size media formats
It hasn’t been that long since document management systems stopped being just for document. Truth is, the term “document manager system” is a term which is used indiscriminately, mostly in Spain and in some Spanish-speaking countries. Companies don’t just store documents. They have other digital assets, like videos, audio files and presentation. As such, it’s more accurate to talk about Enterprise Content Management (ECM) Systems.
SharePoint hasn’t been found to be optimized for the management of this type of files, which stand out for their large sizes in most cases. One easy way of detecting this problem is to see how, in the middle of a request, the search engine will send back a screenshot that tells us that the server is taking a long time to respond.
Problems of scalability in terms of hardware
As we’ve explained in previous sections, the growth of data in SharePoint has been fairly fast, and with it has been the hardware requirements for storing and processing this volume of data. We should add to that the restrictive technical specifications for SharePoint which are not known for their high level of compatibility.
Related posts: Sharepoint: “We can't live with or without you”.