Re: Data Display & Modeling

> One could just as easily state that incomplete adherence to R has cost us
a
> bunch. It's difficult to analyze costs of a model when the limitations of
> implementations of that model (which SQL at one point claimed to be) have
> obvious and well-cited downsides.

I would strongly argue (and this is from the trenches) that problem of less than full adherence to the relational model is not the largest problem in the practical world of what you might call SQL databases. (I'm still looking for another term. How about "tabular databases"?). Most of the trash databases I have seen resulted from the actions of database designers with almost no formal training in db design, and much of that training ill directed.

People who denormalized without even knowing about 1NF, 2NF and 3NF (never mind the highel levels). And, worse, had no alternative design discipline at all to follow, but rather merely tried to anticipate the most urgent query, usually incorrectly.

People who designed a tabular database to mimic a CODASYL or hierarchical database, instead of designing from scratch.

People who crosstabulated the data to make it look more like a spreadsheet.

People who didn't have a clue about the difference between logical design and physical design.

People who didn't have a clue about how much or how little a join costs, with the product they are working with. And not a clue about index design.

People who had not used SQL DML enough to have a good intuition about what a database ought to look like, in order to make it truly easy to program against, and were already launched into designing a major database.

People who just never "got it" about self describing data.

In short, the programming language BASIC made it so simple that any idiot could write a program. And SQL did the same thing for creating databases. And that's what happened! Received on Fri May 07 2004 - 23:11:22 CEST