The last problem is addressed by a traditional (relational) database management system. It also provides a persistent, disk-resident repository of shared data but the persistent data are relations of records instead of files. To create a collaborative application, we simply have to replace the shared file with a shared database, which would now provide the linking among the processes interacting with the user.
Example: Same as the file case except that: We replace the file with a relation of strings in which we store a single record to hold the greeting. An application program uses a query language to insert, modify, and select that record. Since traditional relational databases fix the size of a record, application programs would need to pad/truncate user input.
A DBMS can discriminate among the different records and fields of a database, and can thus provide a finer granularity of sharing, protection, and concurrency control. In particular, it can automate the locking semantics of the bibliography application. In fact, concurrency control schemes in DBMS are more sophisticated than those developed for file systems, providing support for atomically executing a transaction on multiple objects. In contrast, a file system requires users to explicitly lock/unlock all files that an operation must modify and provides no support for atomicity. Later, we will study the subject of concurrency control in more depth.
Another strength of a relational database system is the powerful predicate-based query language it provides for efficiently searching through large amounts of data. The language is particularly useful for searching for awareness information and the status of a shared artifact or a collaboration task. For instance, it automates queries to find all collaborators at a particular location, all talks scheduled within a particular time range, all workflows that are not complete, and all procedures modified by a user. The cost of manually programming such queries in a collaborative application can be high [].
On the other hand, it has the problems of passive disk-resident repositories. An additional problem is that a database system and the processes that access it typically use different representations of data. As a result, a DBMS forces its clients to convert between different representations of data, which is referred to as the impedance mismatch problem []. Impedance mismatch makes the overhead of developing collaborative applications high since programmers must write translation code that converts between the different representations. It also increases the response time of the applications because of the overhead of executing the translation code at runtime. Impedance mismatch is also a problem in single-user applications that use the database to store their persistent data. It is a more severe problem in multiuser applications developed using this approach, since they use the database to also store shared, possibly non-persistent, data such as a scrollbar position or the list of users in a session.
Thus, a DBMS is even less suitable than a file system for supporting real-time collaboration. Impedance mismatch would also occur in the latter if a textual rather than directly binary representation of data is stored in a file. However, even in the case of text files, all information about an application data structure such as a parse tree can be stored in a single, variable-length file. In the case of a traditional DBMS, such a data structure would be spread out in multiple fixed-size records and costly joins would be required to fetch and store all of these records [].