Re: Multiplicity, Change and MV

Tedd wrote:
> I'm curious to know why those companies use multivalue databases.

Yes, I am too. This has been my curiousity and off-and-on area of research for the past few years. In spite of having seen numerous beneifts to the MV model resulting in what appeared to me to be significant budget savings, I was touting the benefits of the RM, normalization, constraints, etc and advising folks to move away from their Pick/MV databases a few short years ago (2001 was likely the last time I was in that camp). My thinking was that products like Oracle, DB2, and SQL Server were making enough gains in tackling some of the benefits of MV (with changes in SQL: '99 and products adding features unrelated to the RM, for example) and had the added benefit of standardization (e.g. ability to point Excel at an ODBC data source) and the mathematical elegance of the RM (e.g. set processing and modeling constraints and facts as propositions, then employing predicate logic).

But my intuition on this changed after gathering some first-hand anecdotal evidence that indicated to me that products based primarily on relational heory might never get to the point where the MV products were in some key aspects. I don't think that Pick is a highly evolved product, but applications built with this data model and these tools have some significant advantages that seem to directly relate to the bottom line for a business.

So, my opinion, without sufficient evidence, is that companies are seeing significant cost savings when they use products such as U2 from IBM. Most of the large companies using MV use other databases too, so they ought to be able to compare. I have listened to stories from several people who were running both and get about an even up case for each -- no clear winner from those in the trenches. I have not talked to "Bob, the owner" in most cases, but the difference seems to split out between those who are budget officers or business-minded (often, but not always, preferring Pick) and those who were CS majors (typically preferring SQL-based tools).

These companies might be able to get a good idea of what the overall cost is for an application built on MV and one built on SQL (and, yes, I know that SQL is not a perfect implementation of the RM). There are so many factors, however, that it is never obvious why there are savings in either direction. Many companies decide that the cost savings related to missing features in MV, such as Excel directly reading the database (unless they suffer the cost of the SQL-MV mismatch), or the industry touting the benefits of the database, or perhaps the application needing a UI makeover. Then they attempt the "upgrade" to a SQL DBMS to get the missing features, often sinking huge dollars into the project, typically with limited or no success.

The reason for the problems might relate to the difference in the logical data model used with one product compared to the other. I've picked two features to start with that seem to help the MV products provide bigger bang for the buck solutions -- Non-First Normal Form data structures (lists, in particular) and use of a 2-valued-logic. These might seem like small potatoes, and they are certainly not the entire picture, but I'm hoping (pushing, in my own way) to see changes in the industry toward both of these in the coming years. After that there are many other topics like the query language itself and constraint management that are likely relevant.

> Is
> it the legacy app that is tolerated because it still works or is it
> because the style of database suits their problem more than a RDMS?

The difference does not seem to be specific to any narrow problem spaces. It seems to cover a broad range of data processing applications and vertical industries. I hope this was helpful. Thanks. --dawn Received on Mon Apr 17 2006 - 21:06:03 CEST