Central database have control and failure
A document management system that employs a central database stores all document profile information in a single, monolithic database. Typically this is a relational database management system (RDBMS) that resides on a dedicated Server attached to the network. As users of the document management system work with documents across the network, the DMS routes all document profile updates and information requests to the server housing the central database.
Typically the database is an adjunct to the documents, which tend to remain distributed throughout the network. Database records therefore contain a pointer of some sort that “attaches” the record to the corresponding document’s physical location. An extreme application of a centralized database approach to DMS, however, foregoes this level of abstraction and actually stores the documents within the database structure, often as a binary large object, or BLOB. While highly secure, this approach can also increase risk of lost documents or impeded productivity during a hardware or software breakdown.
Many DMS vendors have constructed systems that use SQL database technology. Ostensibly, this is to enhance interoperability and to take advantage of the client organization’s existing expertise with the technology, if present. SQL databases offer these benefits:
- some sites can leverage existing SQL proficiency (if present)
- scaleable support for Wide Area Networks
- offers opportunity to consolidate data stores.
On the down side, a single, centralized database containing the entire body of information about a firm’s document repository presents a single point of failure. Without a properly defined and strictly enforced backup regime, the failure or corruption-for any reason-of a centrally stored document profile repository, can be catastrophic. If the sole document profile database is corrupted, restoring any lost information becomes a drop-everything, mission-critical operation. Even with current backups, at a minimum the DMS-and probably the network as well-will have to be “brought down,” bringing productivity to a standstill.
While the potential for a “doomsday” DMS scenario is not necessarily high in well implemented and well maintained systems, it does happen from time to time. Stories abound of firms having to stop all work, search for the latest backup tapes-or worse, of having to recreate document profiles from scratch.
The more likely scenario on the downside is that the server hosting the centralized DBMS may go down. Without a redundant system in place, such as mirroring, the loss of the server will generally enforce a network-wide work stoppage.
In large organizations with the staff and the know-how, an SQL back-end to a DMS can prove beneficial on several fronts. However, in smaller organizations, or those lacking in-house SQL expertise, a dedicated SQL database can prove to be a serious resource drain, both on the network and on budgets that are bound to expand in order to accommodate outsourcing SQL database expertise. SQL databases are powerful, but that power comes at a cost.
Be assured that installing an SQL database is in no way a turnkey operation. It takes studied expertise to set up the database, and ongoing tuning, backups, and continual upkeep in order to keep it running within acceptable performance limits.