Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Table design for application options

Re: Table design for application options

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Mon, 20 Dec 2004 23:56:33 -0600
Message-ID: <cq8dui$mf0$1@news.netins.net>


"B-17" <mhammer111_at_msn.com> wrote in message news:1103603212.298790.79290_at_f14g2000cwb.googlegroups.com...
> I'm sorry -- but it really puts a damper on the holidays to mention
> Pick, Unidata, Universe, Revelation, Reality (Microdata), Prime, or any
> "multivalue" system in the context of a what is supposed to be a real
> forum concerning data management.
>
> As a note, it's not a matter of their design being outdated, but
> totally incorrect.

Since tag=value was considered correct for this purpose, and many readers know I've been researching both Pick and Relational, I figured I'd make it clear that such a strategy pre-dates relational theory.

Of course many on this list know that I think when we adopted relational theory we threw the baby out with the bath water, thus setting back the profession. Some are concerned that XML could do something similar so they are digging in their heels as being anti-XML. It just looks to me like we are acknowledging that data can be viewed in di-graphs as well as sets after a couple of decades of di-graphs being dismissed after being labeled "networks" or "hierarchies" and THEREFORE ??? bad. I'm all for looking at data as relations, but it is also helpful to work with data in graphs. That's where good ole' pick had things working right.

You seem to have some history with the products. Is your concern that they are old and most apps using them are still character-based, that they are non-1NF, that metadata is descriptive rather than prescriptive, that constraint handling is done in the application logic, that it is loosely typed, or that most systems use DataBASIC as a procedural language with the database, or ... ? I have had all of these concerns.

You are right that there is nothing "correct" about it. That's where I had a problem with it coming into a Prime Information shop in 1989 as a new manager after using IMS, following the evolution of DB2, and dabbling with Oracle. I told my team I would research the model so we could discuss whether we should look to migrate to an RDBMS. And it bugs me to this day that it showed itself to be a very big bang for the buck environment compared to anything I saw before or after. Someome just mentioned on comp.databases.pick that Progress is another big bang for the buck environment. Cache' (from the Mumps camp) has been doing well in recent years. These are all old pre-relational databases with one thing in common -- they provide an excellent value to those who license them.

That's what triggered my research into relational theory and SQL-based solutions. If you put two similar companies side by side, one using an IBM U2 product and the other using Oracle, which company will spend the least to get the most from their system? Which one scales better? Which has better performance? Which requires fewer hardware resources? Fewer people to support it? Easier maintenance of the software? Which yields better productivity for developers? I am not certain of the answer to all of these, but if you were "Bob, the owner" and this were YOUR MONEY and these were your two choices, which would you choose?

So, yup, it's "incorrect" -- makes you (or at least me) wonder whether we, as a profession, have properly defined "correct". I think the answer to date is "nope".

Does that help with the holiday cheer? --dawn Received on Mon Dec 20 2004 - 23:56:33 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US