From: SB
To: Editor 

 

Having enjoyed your recent book, PRACTICAL ISSUES IN DATABASE MANAGEMENT, once I managed to obtain a copy (!), I would like to thank you for a very reassuring read. Unfortunately, before I had received your book, I had not come across much literature that contained any common sense.

 

Most stuff emphasizes what can be done, rather than what should be strived for! I have assumed that the writing style reflects your passion for the subject, and I must say I did get very angry with the book. Not with you at all, but I sensed that you were getting really frustrated with current database 'design', and I felt myself getting angry at the same time as you... I found relief, too, in that many of the ideas I had been thinking about, and general feelings about how things should be done, I suddenly found in your book. I was very pleased to see that I need not feel lonely any more!

 

Anyway, enough of the (sort of) compliments, I have a few brief questions I would be grateful if you could answer please:

 

1) Would I be correct in asserting that SQL was designed as a query processing language for alphanumeric lists; i.e. that the 'Q' in SQL emphasizes that the language was developed for designing queries, and not as a data/table definition language. Therefore it is not surprising that manufacturers have made such a poor job of implementation. Perhaps it is like most other things, where manufacturers extend languages to do stuff they were never designed to do, such as 'everything', and then wonder why their products get a bad name (and consequently end up doing 'nothing' of much worth)?

 

2) When you discuss the flaws in SQL, do you know if Oracle 7/8/9 is based on the SQL'92 standard, and consequently still suffers from most of the problems you describe?

 

3) Would you say that because database triggers circumvent database integrity, and so should be avoided, they are best replaced by a combination of:

   a) Primary key constraints.

b) Moving data check resolution triggers up to the application level using validation and verification field update checks in data entry fields instead.

c) Moving other 'triggers' down to the physical level such as those concerned with how the data is stored across data volumes etc, which may be part of the RDBMS anyway)?

 

4) Would you say that Oracle doesn't really have a front end table definition interface, unlike Access, where in the latter you can design tables graphically, which are native to the JET database engine, thereby avoid the shortcomings you mention in creating tables in SQL?

 

5) Would it be correct to describe an environment that uses the incidental linkage of small, discrete databases that reflect single world entities as 'atomic component databases', and the whole as a 'single virtual relational database'?

 

6) Would you consider it efficient and sensible to store all text field entities in a single list, indexed by a surrogate positive integer index (1,2,3...), and then using this now foreign key in other tables to define the links between the records, so you only then need to use integer fields in the other tables? This could be rather like using Oracle bit map indexes, and taking normalisation to perhaps a rather far extreme.
 
 

Fabian Pascal Responds: 

 

1)     It is true that SQL was designed as a prototype query language for System R, the IBM relational research project and that it originally did not include data definition and other data language functions. However, IBM was warned by both Codd and Date--at the time IBMers--that SQL had serious flaws, not the least of which was missing functionality. Codd proposed his own language Alpha, but was ignored because IBM was eager to make SQL available commercially--expediency overrode all that "theoretical stuff". While much of the responsibility for SQL's weaknesses and flaws lie with IBM, it is also true that most vendors of DBMSs based on SQL (not to mention the ANSI SQL standard committees) have equally ignored relational and good data language design principles in implementing SQL. There is plenty of blame to go around.

 

2)     I am no longer following product specifications, because they have been getting worse, not better, when it comes to relational fidelity. In fact, the standard committee recently added pointers and objectification to it, throwing it back decades. My guess is that it would be fair to say that products have not gone beyond SQL92, except for proprietary extensions not very well thought out. Of course, this does not mean that they implemented all standard specifications, or that they implemented them the same way.

 

3)     Triggers do not "circumvent database integrity" -- if supported by the DBMS and correctly implemented, they are better than application-enforced integrity, which does circumvent database integrity. However, they are not a substitute for declarative database integrity for a variety of reasons (as I explain in my book).

 

4)     There are probably quite a few graphic interfaces to Oracle and I do not recall criticizing products for lack of graphic interfaces. That is essentially an application, not DBMS function.

 

5)     I'm afraid I do not understand the question.

 

6)     Ditto.

 

 

Posted 04/05/02

 

 

 

[ABOUT] [QUOTES] [LINKS]