Re: O'Reilly interview with Date

From: David Cressey <david.cressey_at_earthlink.net>
Date: Sun, 14 Aug 2005 11:29:02 GMT
Message-ID: <2WFLe.5862$Je.1652_at_newsread2.news.atl.earthlink.net>


  1. With regard to data modeling, you can't define attributes which are of complex types (arrays, records, tables). Each relation has to be in first normal form. Or in other words: A "simple" natural structure must be divided into many flat structures (= tables/relations). The result is a complex structure of relations.
  2. Result of a query is a flat table. Any complex structure, which has been input of the query has got lost.
  3. No way to define recursive program structure (using SQL).
  4. The type system of SQL doesn't match with the type system of the embedding language ("type mismatch").
  5. Controlling integrity constraints costs a lot of time (need to control the usage of primary/foreign keys).
  6. Lack of mechanisms to control the physical level of the database (only simple clustering).
  7. Definition of operations detached from data definition.

With regard to Date's response to alleged weaknesses in the relational model:

Date's response to 1. and 2. Date is right, up to a point. But his phrasing is unnecessarily disparaging. Not everyone in the field agrees with Date's definition of 1NF, and not everyone who disagrees with Date has a "misunderstanding".

Second, the result of a query, in the real world, will be limited by the capabilites of a real live DBMS, not just the limitations of the formal model. If you are building a relational data model as a prelude to building a physical model, then it behooves you to sidestep limitations that are going to become showstoppers at the physical level.

That's the only reason to avoid, in logical modelling, reliance on queries whose results do not confomr to what Date calls the "misunderstanding of 1NF".

Date's response to 3 and 4. Date is right. These are (or were) limitations on SQL, not limitations on the RDM. But SQL is (or was) and evolving standard. There's nothing to say that a future revision of SQL won't deal with them.

Date's response to 5. Date is right. More disasters have happened, in the real world, by omitting needed controls on input data than by establishing these controls and paying the performance price. In practice, many real live databases have relied on the input data stream to conform to the constraints, and later found that the input stream was not, in fact, reliable.

The ultimate question of WHERE to enforce compliance with constraints is a physical modeling question, not a logical modeling question. The ultimate question of WHETHER to enforce compliance with constraints is a data management question that pervades the graph (hierarchical and network) models, the object oriented data model, and other data models, as well as the RDM.

6. Date is right. objection 6 cannot be understood as an objection to the RDM, unless it's an objection to the separation of database data objects (like TABLESPACE) from schema data objects (like TABLE). If that's what objection 6 means, then objection 6 is just plain wrong.

7. Huh? Received on Sun Aug 14 2005 - 13:29:02 CEST

Original text of this message