Re: Object-oriented thinking in SQL context?

Walter Mitty wrote:
...
> Something analogous happens with database design. People who begin
> designing databases based only on prior experience with indexed files, and
> who expect to put all the business logic in the application, end up with
> databases that are clumsy, slow, and fairly inflexible. ...

Since business 'logic' is so rarely expressed logically and since most practitioners have no logical training and haven't bothered to learn relational algebra, which parallels classical logic in sets (and possibly exceeds it in expressiveness), this shouldn't be a surprise. In other words, most practitioners, no matter whether they call themselves OO programmers or DB designers have not spent time understanding the implications of the theory. If they had, it would occur to them that relational theory doesn't mandate where attribute values come from. They would also have realized that the theory points to practical implementation questions, such as "is the work to produce such and such an answer in proportion to the answer?".

Most of what's published offers no foundation to achieve this understanding, being mostly recipes and examples from which it takes extraordinary effort to distill the essence, as opposed to blindly following. Most "newbies" don't even have the advantage of long-time trench work so it is hard for them to see the lessons of history and avoid repeating very old mistakes.

It seems such understanding is hard for DBMS implementers too, witnesss the PhD's in the System R team who not only read Codd but sometimes worked in the same building with him. They saw quantification in his calculus bits and must have thought they could implement that, they saw his algebra and must have thought they could implement that, as long as they used bags instead of sets and ordered attributes instead of naming them, they saw R-tables and thought they could implement those. They ended up implementing some kind of bastard table theory.

It may well be that one cannot read Codd to see his real intent without a knowledge of the times during which he wrote his first papers. It will be obvious to anybody who worked around computers then that he was deliberately making his points in the context of IMS-style db's and the file systems of the day.

I doubt if one in ten posters here could express a simple key constraint algebraically. While implementing keys that way would be silly, one will not have a solid foundation for understanding the uses for keys without being able to do it on paper. As various posts here show, there is wide-spread confusion about more subtle constraints, such as transition constraints. Without a basic understanding most posters are reduced to mysticism.

The essential relational theory is very small, in text, it's perhaps only one percent of the size of the SQL standard. I would go so far as to say that it needn't include type theory. Somebody here referred to "data modellers and database designers who have to turn theoretical concepts into database schemas". Well actually, hardly anybody has to do that, to some degree or other, the theory will have already been "turned into" a dbms, no doubt incorrectly in places. The sensible practitioner needs to know what those places are, so that he can recognize the deviations from theory. There are regular questions here along the lines of "I have this application, but I can't identify the attributes I need". Well, actually, those posters are dreaming, they do not even "have" an application, because they cannot even name what they are talking about, which is a sine qua non for entering into design. This leads to endless talk about "what is an identifier?", which is not a relational theory question. It is a consequence of the faithful technocrat's blind reason to want to see apps where there are none and there are some here who will grope endlessly in that pursuit. They are actually talking about interpretations about which relational theory says nothing. They habitually fail to recognize this and refuse to offer any kind of formal interpretation theory. I suspect Darwin (not Darwen) if he were alive today would recognize the mystic guild as one of the natural manifestations of his ideas.

In fact, they are talking stupidly and I think of it as an evolutionary necessity to call them on that, the goal being not to illuminate the poster, but to remind naive non-posters that the full moon is once again on the rise. Some people are too stupid to know they are stupid, but those aren't the people of interest. Any student of history will know that progress and politeness are contradictory. The people who are capable of both reading and thinking will also occasionally say something stupid but that small minority soon stops huffing and puffing and re-asseses their position.

OO programmers should get off their various indulgent cans such as 'reuse' and try to realize their place in all this, apart from the rare true simulations, in an ideal evolution of the world their purpose would be mainly to provide equality tests for types, sometimes they might be permitted to code GUI event handlers. For evidence they need only remember the questions they were asked at their commercial job interviews, most of which would not have needed any fundamental knowledge in order to answer. Received on Tue Jun 09 2009 - 19:13:33 CEST