Re: Lucid statement of the MV vs RM position?

Pickie wrote:

> There doesn't seem to be a formal model anywhere.

Which limits the application of anything resembling a formal method.

> Integrity
> constraints are not enforced at the database level.

Which is a central database management function.

> Pick 'sort-of' looks like everything, but is unique - and
> very useful.

We have already established that it has less utility than most of the alternatives. How does that make it 'very useful' ?

> http://www.pickwiki.com/cgi-bin/wiki.pl?PhilosophyOfPick gives my views
> of the philosophy behind Pick. I think even Bob would agree with this
> quote - "In the Multi-Value model there is no DBMS as such."

Why would you compare a model and a dbms. I would agree that at best primitive file processors like Pick are nothing better than dbms construction kits. I have seen several NFNF logical models, but I have seen nothing I would call a concensus on an MV model.

> The above are informal descriptions - I certainly don't have any
> pretensions to ability at higher mathematics. C.D.T. certainly is the
> place for someone to raise this issue, and the lack of a formal
> definition is frustrating. But I'm not sure that Pick IS the right
> thing to have a formal description.

See Dijkstra's comments on the illusion of power.

 > It seems to me that there is
> something missing, in that it does not enforce constraints. In my
> view, one uses Pick to build an application which is, itself, the DBMS.

Doesn't this then require every pick application developer to have the rare expert skills of a dbms developer? Do you think it is wise to require such expertise from all developers?

> There is a mindset about the Relational Model that is disturbing. The
> point of view that says that there is no TRULY Relational DBMS because
> of incompetance or wickedness on the part of the SQL DBMS providers is
> just outright wrong.

Why is it wrong to point out actual incompetence? The profit motive is not wicked, but it is the profit motive. If it is cheaper to baffle people with bullshit than dazzle them with brilliance, what outcome would you expect?

 > The problem is that it is difficult in the
> extreme to build a data store of whatever size desired, that can have
> some arbitrarily huge number of people changing the data in it, and
> that will provide the answer to any conceivable query - as if the data
> store were to be frozen until the query is done.

Ironically, it is easier to build a relational dbms than a non-relational dbms.

 > Every time you put an
> index in, or some other cute little wrinkle to more cleverly do this,
> you are argueably de-normalising your database.

Ignorants can argue anything. That doesn't mean the arguments even begin to rise to the level of legitimate discourse. Normalization is a logical concept and indexes are physical structures that do not affect the logical view of the data. As such, any argument related to indexes and normalization is just plain old dumb.

 > Well, you are storing
> data in multiple places, anyway.

True. But if redundancy achieves the desired performance characteristics and is entirely managed by the dmbs, what is the objection to the redundancy?

> The idea of having a horrendously complex physical implementation - in
> order to provide the appearance of a clear logical model - is
> uncomfortable to me.

Physical implementations in heterogeneous hardware environments are by their nature horrendously complex and performance requirements often increase the demand for physical complexity. Physical independence and a clear logical data model serve to alleviate (often obviate) the need for casual users to account for this complexity.

As a general principle, one seeks to shield human users from complexity not relevant to their needs. What about this principle disturbs you?

 > I question, not the Relational Model, but whether
> implementing this aspect of it in this way is worth the trouble.

Have you considered the consequences of doing so? Fewer errors. Better overall performance. Greater utility for more users. Higher reliability. Greater availability. Easier maintenance.

How much trouble are those benefits worth? I think they are worth a lot of trouble.

> Were there any formal definitions of the Heirachical and Network
> Models? I was going to write "exempting the ones that Codd set up in
> order to show the RM was better", but then I realised that I haven't
> even seen these, and that maybe they would teach me something. Does
> anyone have a link to them?

 From this article by Chris Date, the footnotes identify several sources of the paper:
http://www.intelligententerprise.com/db_area/archives/1999/991105/online2.jhtml

1. Codd, E. F. Codd and C. J. Date. "Interactive Support for Nonprogrammers: The Relational and Network Approaches." IBM Research Report RJ1400 (June 6th, 1974). Republished in Randall J. Rustin (ed.), Proc. ACM SIGMOD Workshop on Data Description, Access, and Control, Vol. II, Ann Arbor, Michigan (May 1974). Also in C. J. Date, Relational Database: Selected Writings. Reading, Mass.: Addison-Wesley (1986).

I suggest a used copy of _Relational Database: Selected Writings_ would be the wisest investment of the options given. Received on Fri Apr 21 2006 - 02:50:35 CEST