Re: 4 the Faq: Strengths and Weaknesses of Data Models

From: Laconic2 <laconic2_at_comcast.net>
Date: Thu, 14 Oct 2004 07:38:33 -0400
Message-ID: <o8CdncdM_YfU-PPcRVn-jA_at_comcast.com>


"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:n53kkc.0h1.ln_at_mercury.downsfam.net...
> It seems to be taken for granted by the majority in this ng that the RDM
is
> superior to the hierarchical and network data models. I am in that
> majority, but I realize it is probably for me more a matter of faith than
> proof.

Codd dealt with the comparison between network models and relational models in his 1970s paper.
Most of what he said in that comparison is still true today. That was analysis, not just faith.

>
> So the question is: why did RDM win the database wars? Was it really on
> strengths, or was it, shudder to think, just one of those trends that IT
> goes through?
>

I want to answer an easier question: why did VAX Rdb/VMS win out over VAX DBMS? That's an easier question for me, because those two products have a lot in common. They both run under the same OS, they are both accessed from a lot of the same programming languages, and they share a certain amount of internal code.

Fist, let me tell you what it was NOT! It wasn't speed. With a suitable amount of tuning and opimization for a given application, you could always make VAX DBMS outperform VAX Rdb. A relevant network of pointers will outperform an index any day of the week. Eventually, Rdb won on performance, but that was because work on DBMS stopped moving forward.

Here was one thing: ease of learning. You have to learn a LOT before you can make your first VAX DBMS dataabse, even a tinkertoy one. You can learn enough to make a five or six table Rdb database in an afternoon. I used to teach a one week programming and design course for Rdb. Building a database was on Friday. Learning good column design, good table design, and good index design takes a lot longer. But you can get started easily.

Next is flexibility. Dan put it quite succinctly: more data independence. I want to expand on that, although informally. Let's say you want to expand ZIP codes from 5 digits to 9 digits. With VAX DBMS, you are tyically going to have to unload all the data, recreate the schema and reload. With VAX Rdb it's more like:

ALTER DOMAIN ZIP_CODE char(9);

Rdb will run around and find all the columns that were based on the ZIP_CODE domain, flag the appropriate relations as out of date, and arrange for subsequent queries to convert the old format to the new format, and subsequent inserts to insert the new format. Real easy.

Let's say you discover that you really want an index on city and state. You can create the new index without unloading data. The same old queries that were scanning the tables will now run faster.

Let's say you started out with a parent child relationship between customers and orders, and between orders and order items.

Now let's say you want to set up another parent child relationship between products and order items, and you want to do complex queries that can inform marketing decisions like: how can we find new products for our existing customers, or how can we find new customers for our existing products? These questions weren't even being asked when the order processing database was being set up.

Setting up this sort of thing is fairly easy in Rdb (if you know what you are doing). It can be done in VAX DBMS (a network database), but it's a real pain, and the trade-offs involved in using the same data for marketing analysis and order processing are quite ugly.

It's dang near impossible in the default database that comes with a product like FOCUS. FOCUS was built to be used with somebody else's database, but they include a hierachical database with FOCUS so you have something to work with if all you buy is FOCUS.

> What is normally stated in the group is that RDM has a mathematical basis
> that gives us a strategy for correctness, which Hierarchical and Network
> did not. Yet somebody in this ng mentioned a few days ago that those
> models were given a more rigorous footing later on. Could the
hierarchical
> model now be just as thorough, except that RDM already won?

Many of the "internal databases" that keep track of objects and messages in systems like the Java run time system could really be modeled as network databases. They are alive and well. It's just that if you want to leverage value out of data, data independence tends to win out. Received on Thu Oct 14 2004 - 13:38:33 CEST

Original text of this message