Re: Is relational theory irrelevant?

"Serge Rielau" <srielau_at_ca.eye-bee-m.com> wrote in message news:bpdge7$pv$1_at_hanover.torolab.ibm.com...
> Joe "Nuke Me Xemu" Foster wrote:
>
> > "Serge Rielau" <srielau_at_ca.eye-bee-m.com> wrote in message
<news:bpc4ci$ogk$1_at_hanover.torolab.ibm.com>...
> >
> >
> >>Ragarding c) the realtional model is built for semantic beauty. Semantic
> >>beauty does not make for a fast web-experience. Pipelining however does.
> >>So a lot of effort is being made to pipeline SQL. Often the rules of the
> >>relational model are bent to get there.
> >
> >
> > This is because SQL is so b0rked. Query optimizers' hands are
> > tied because most any transformation could change the results.
> >
> >
> >>Example:
> >>SELECT * FROM (SELECT sendmail() FROM T) AS X WHERE c1 > 100;
> >>How many emails shall be send? Correct (IMHO) would be: As many emails
> >>as there are rows in T. In reality many DBMS will push the predicate
> >>through to T for the sake of speed, and most customers evidently don't
care.
> >
> >
> > Agreed, queries calling functions with side effects is b0rked.
> >
> >
> Interesting. I didn't intend to allege that side-effects are bad. They
> are a reminder that SQL has to deal with the real world.

If theory does not deal with "the real world", I sometimes wonder what world does it deal with!
What I will take you to mean, is that most theory is necessarily narrow in scope, and that "the real world" contains many things not in the scope of a particular given theory.

In this case, we certainly do need to use other theories, not just relational theory, to explain the current state of things, and the possible/probable state of future things. That we need something other that theory though, is rather a contradiction IMO.

> Just because soemthing is "out of the databses" interest still requires
> the DBMS to deal with it because it is in the customers interest.

Agreed. In fact if something contains data, then it is the interest of some model of data, and the relational model of data is probably very often the best model to choose (even if say persistence and application independence are not required for the data in question). That the relational model has not penetrated much outside the area of data persistence is a consequence of the too narrow scope of applicability that has generally been applied to the model IMO.

> On the general topic of education (and smoking). While ceasing to do a
> bad thing is a fairly simple thing mentally. Educating someone to
> actively think a different way (our brains are not wired in relational!)
> is a lot more "expensive".

Humm, how "natural" is relational thinking? E.g. one could suppose that separating information into structure and data (like say a hierarchal model) is somewhat more in tune with what evolution has tuned us to expect of the outside world, or one could suppose the opposite, that our brains do tend to ignore such structure/data distinction.

I guess that congnative scientists could do some experiments on this. Maybe a large %age of the population has "dys-relationa", whereby they find it extremely difficult to learn the basics of the relational model. If the above is true, then indeed we should cater for this. Maybe we have to keep the model to some 'elite' that can be trained to understand it, and so give up on our hope of letting users work directly with relational databases...., ...

> Given the amount of work there is do do in
> the space it is simply not possibly to man the projects with properly
> educated people because teh education woudl be either too epxensive or
> there are not enough people available who actually can think be made to
> think relational.

Of course, the thing is that I believe relational to actually be*much easier* to understand (*if* you can catch people earlier enough in their education) not least beacuse there is actaully very little to the relational model!
However, I might be incorrect in this belief. I know of no rigorous studies into the relative cognitive ease of understanding of different models of data. Lots of personal and anecdotal evidence suggests to me that relational is not too tricky to learn, esp when presented clearly and with a sandpit to try out one's leant knowledge. Plus, something that is simple, should be pretty easy to learn (unless it *really* goes against innate preferences)

> Let me stick with health and education here. But let's talk about
> healthy food. As long as I require people to cook (write queries) there
> is a big need to educate them about what food is good (and how it can go
> bad). Certainly I know neither how to cook nor how to differentiate
> between good-carbs and bad-carbs. To anable these healthy lifestyle
> choices one needs to embedd it a lot mor thorough (highschool) at the
> cost of other education.
> Teh same woudl be true for SQL. It woudl be required for each college(!)
> diploma to have MORE SQL classes, explaining the model a lot deeper. But
> that increases the length of studies or requires to kick out other stuff
> (Java, C?).

Frankly I would like to see LESS SQL and more fundamentals. SQL should be explained from the point of view of how it can be used to implement *relational* queries and assignments, rather than be the focus of education itself.

E.g., one should discuss quota queries using a relational language (such as a D) and only then show how such things can be simulated in dialects of SQL.

Serge, I'm sorry to say this, and things are never black and white; but I suspect that you might be more part of the problem than part of the solution. Lack of expresability in some relational languages is also part of the problem (Tutorial-D not excluded), and your work to improve SQL's expressability is defiantly appreciated, but it certainly true that SQL is ultimately, eventually part of the problem, and that if you think that more SQL classes would significantly improve things, then I do feel you are somewhat mistaken.

> Cheers
> Serge
> --
> Serge Rielau
> DB2 SQL Compiler Development
> IBM Toronto Lab

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Tue Nov 18 2003 - 23:18:08 CET