Re: Lucid statement of the MV vs RM position?

What one does with a Pick-type (MV) system, is build an application. Some of the tasks of a DBMS are carried out - like record locking, triggers, and transactioning - by the MV system automatically. Other tasks, like constraint checking, are usually carried out by the application program. There is enough provided in the MV system to enable a total application system to be as good as a relational DBMS without requiring the capability of building a DBMS.

Perhaps I should have called it a database construction kit, but I thought the result was so much more than a database that 'DBMS constructor kit' appealed to me.

It is possible to build different applications which use the same data files. This is not usually done by independant teams if the data is to be modified.

It is possible to use SQL, but if this involves modifying an existing application to follow SQL rules (such as not allowing the full stop in a column name) then usually it's not worth the financial cost.

Multivalues can violate first normal form in the same way as using the internal file, block, and row numbers instead of a key violates Codd's guaranteed access rule. That is to say, while it may be possible to do something, it may not be good practice to do it. Multivalues are correctly used if they are seen as a compact storage method for 'child' relations. They partially automate cascading deletes which otherwise would require application programming.

In my opinion, MV databases tend to collect rubbish data, but the applications do not fail catastrophically because of this. Usually the rubbish is only discovered when migrating the data to a DBMS, or investigating the possibility of doing so. Obviously, these ones are not quite "as good as a relational DBMS". However, this cruft seems to gather as the conceptual model evolves, so maybe at one point it was "as good as". Received on Wed Apr 26 2006 - 02:59:04 CEST