Re: Is relational theory irrelevant?

Serge Rielau wrote:

> When looking at relational algebra on one side and application
> programers at the other there is one problem:
> Application programers outnumber academicians by 100:1.
> The application programer who truly understands realtional processing
> is a rare exception.
> Any company that tries to map the theory to teh praxis will therefore
> have to make compromises between:
> a) keeping the model clean
> b) making the language usable by the users (application programers)
> c) making the execution fast.
>
> No need to talk about a) in this group I suppose.
> W.r.t. b) application programmers thing procedural.
> Nested queries are pushing it. Therefore a lot of what you see out
> there is a simpel SQL braced by a lot, a whole lot, of procedural
> logic (be it PL/SQL, T-SQL or SQL PL). Any attempts to ignore this
> fact will be punished. As evidence I point to SQL Server's success in
> the marketplace: Simple SQL with a really fast, application develoiper
> centric, procedural icing.
>
> 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.
> 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.
>
> I personally often wish I worked in academia where I could fix the
> system of it's legacy bugs and most importantly always place my
> version of correctnes above all.
> Unfortunately what is fueling the industry are the customers and not
> academia. And all I can do is try to walk that fine line between
> earning my money and resisting to break the model.
> My only salvation is the firm knowledge that those who break the model
> bad, shall be punished with maintenance of it for ever.

I think your points are quite valid. A couple of comments:

If we were talking about smoking we could all agree that smoking is bad for your health, but on the other hand we obviously can't forbid smoking. So we should make a
distinction between talking about what is good in principle and what are the practical realities.

Now to get people to stop smoking and help them adopt a healty life style takes a long time
(lot's of education, new laws, maybe new products) and there will still be some smokers around.

Now I, as a non-smoker am happy of all the smoking prohibitions in place (at least in Finland) so that I do not have to smoke passively against my own will - I can decide to breath fresh air.

Now the situation in database management products is such that there are no real alternatives to SQL and it
is taken for granted that you either use it or just don't use DBMS-products. So I have no real choice.

And on top of it, the ACADEMIA is actually SUPPORTING the "tobaco companies", so to say, helping them build better cigarettes and not really trying to build an ideal "smoke free" world, as they should. All talk about alternatives is framed as unrealistic or non practical. The alternatives MIGHT be non workable in practice, but we will never know, because little work is done to advance the non-SQL world. Or work has been directed towards OO-databases, and now, more and more, towards XML-stuff (in the latest VLDB conference (see www.vldb.org) about half the presentations were on XML).

So while I can accept that people smoke and that I have to inhale the smoke myself, it is hard for me to understand why so little is being done to get to a "smoke free" world, unrealistic as such a vision might be.

Taking the practical question of optimising quota queries and other complex constructs the VISION is that if we have a clean model it is easier to build optimisers for these constructs and we can, in fact, HIDE most of the complexities from the application programmer by using views etc. So knowledgeble people could build tools, like complex datatypes and views (much like the math and graphics libraries we have today) for the "normal" application programmer.
Or, perhaps, we would not even need so much programming any more, but instead could generate most of the application automatically.

Now it might be that this vision is totally unrealistic, but we will never know if we are not even willing to try.

regards,
Lauri Pietarinen Received on Tue Nov 18 2003 - 12:22:08 CET