|
|
MemCom is a data management system, but not a relational database management system: There is no support for higher-degree relations, and consequently there is no relational algebra. There is also no support for constraints and specifically, no support for referential integrity.
MemCom does not provide full data integrity, and specifically no support for transaction roll-back (that is, undoing all changes in the database a transaction has made so far). If you work on a MemCom database and your application crashes, or worse, your system crashes, chances are (due to the design of MemCom) very good that your database's integrity remains intact and you can continue to work with that database. But there is no guarantee for data recovery. If data integrity is your foremost concern, then you should look for a database management system with support for ACID-transactions.
In contrast to MemCom, most relational database management systems (RDBMS) implement these features. But implementing them incurs a very considerable performance overhead and makes these systems huge, complicated, and more error-prone. This leads to higher demands in hardware and manpower. If data integrity and higher-degree relations are not absolutely necessary, the total cost in using an RDBMS is much higher than that of a data manager like MemCom.
To illustrate the overhead of transaction roll-back, it suffices to imagine n active transactions writing each m bytes of data to the database. Because each active transaction must be able to roll back any time, there must be m * n bytes of data stored separately until the transactions commit or roll back. This implies a storage overhead of m * n bytes (m being the maximum number of concurrent transactions and n being the maximum number of bytes per transactions), and a performance overhead of (m * n) / d, where d is the I/O throughput (bytes/s). Depending on the values of m, n, and d, the overall performance of the system is seriously impaired.
Another disadvantage of transaction roll-back is the fact that the application must be programmed for it: Any time a transaction may be revoked and the program must be able to detect this and to re-start the transaction, re-initializing its data structures. Implementing this properly and efficiently means a considerable amount of effort, adding to the total cost.
Finally, in the domain of scientific computation, where calculations can easily take days, roll-back due to resource conflicts on the database is unacceptable. In this case it is much better to resort to simpler solutions such as serialized access to the database to avoid resource conflicts in the first place. In client/server-mode, MemCom enforces such serialization among concurrent transactions by default.