In Defense of the Multi-Value Database

Reading Andrew E. Wade's chapter "Business Objects in Object Databases" of Andrew Carmichael's anthology of OO practitioners "Developing Business Objects" from 1997 I am struck by the parallels between the advantages of Object Oriented databases and Multi-Value databases over RDBMS for complex business modeling such as ERP systems.

RDBMSs provide a simple, flat, tabular view of all information. The user must map his application data structures, whatever they might be, into those tables. Other traditional database systems require similar mapping down to simple, flat records. The user must work at the level of only the table data structure and only a small set of simple operations (select,project,join). Now, if the application data structures is naturally simple and flat, and the application operations are also simple, this mapping is straightforward and not an issue. On the other hand, when the application structures and operations become complex, the RDMBS approach forces the user to deal with this directly. An ODBMS offers the ability to model an application in terms of objects, which may have any user-defined structure and any user-defined operations. Applications that require nested structures, dynamically varying sized structures, many-to-many relationships, and complex operations can map these directly to objects. Not only is the support far more efficient, far faster at run time, but the user may work at higher levels of abstraction. Instead of translating the application down to records and tuples with joins, the user can work directly with objects such as customers or manufacturing processes, and the natural, application-defined operations on these. The result is easier and faster for the developer and the end user. ...

When to Use an ODMS

... Second, if the application's information is complex and interconnected, an ODBMS can provide much better performance and ease of use. To contrast, if the information being modeled consists of simple, flat, fixed-length field, that fit nicely into tables, an RDMBS can be a fine fit. On the other hand, if the information contains complex structure, nested structures, dynamically varying sized structures, including images, audio, and video, all these can be represented directly as objects. Saving the need to translate not only eases the developer's load, but also eliminates the need to translate at run time, making it faster. To some users, the interconnections in their information model are even more important. In an RDBMS, such relationships are represented by creating secondary data structures, foreign keys. At run time, the system searches down two tables, comparing key values, until it discovers two that match.This search-and -compare process is called a join, an it's the weak point of relational technology. Even with the help of indices, it's slow, and the bigger the database, the slower it gets. In an ODBMS, there is no need to create and manage secondary data structures... Referential integrity, a difficult issue in traditional database systems, comes along automatically and easily. Moreover, the traversal is direct, with no need to search or compare, resulting in performance that is orders of magnitude faster. The more relationships, the more the application will benefit from an ODMBS.

Although to my way of thinking the most critical advantage of Multi-Value databases is their elasticity. They accomodate change. And change is the greatest challenge to software development and software field operations. One example of this is the ability to add domain specific vocabulary to a database in the field. The I-Descriptor feature in file dictionaries allows one (among other things) to describe how the system should retrieve a single foreign field. This is, effectively, a class definition for a field level join. Once defined the foreign sourced field may be used as if it were local for query and record selection purposes. Some users shy away from creating new custom dictionaries, but I see this as teaching the database how to be more useful to the users, how to be more functional in the users natural business vocabulary. Some argue that Multi-Value is dead. I hear this mostly in context of sales and marketing. But the absolute dominance of the healthcare sector by Intersystem's Cache and its predecessor MUMPS would seem to contradict this assertion. Critics will point out that Cache is not Multi-Value, but it most certainly is NOT first normal! In fact, one can argue that the Multi-Value database design is a subset of Cache's architecture. I would argue that the default Multi-Value Telnet based UI is the major problem for sales and marketing. Cache supports HTML as an immediate client protocol. This has been a conspicuously missing piece in U2 and other Multi-Value vendors offerings. While there are many ways to mix-in HTML client protocols such as UO, RBO, BlueFinity, or developing your own data components as we did on the Manage 2000 team, these all introduce tons of extra complexity. On most Multi-Value platforms there is no native MV Basic way to simply and directly code HTML UI's.