Re: Is relational theory irrelevant?

"Serge Rielau" <srielau_at_ca.eye-bee-m.com> wrote in message news:bpc4ci$ogk$1_at_hanover.torolab.ibm.com...
> Intersting thread you folks have goin here, hope you accept late arrivals.

You are always more than welcome here Serge. Not that anyone can stop those that are unwelcome, but that's a different issue.

[snip]
> 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.
[snip]
> 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.

IMO such side-effects (even though one could argue that sending emails is outside the interest of the databae), should only be allowed when tied to database value changes. I.e. I would have done things like this:

CREATE TABLE Request_Email_Send (

    Request_ID INTEGER NOT NULL PRIMARY KEY , Header EMAIL_HEADER NOT NULL
, Body EMAIL_BODY NOT NULL
) ;

/* now, making up some syntax */
CREATE ASYNCRONOUS AGENT Mail_Sender ON
INSERT INTO Request_Email_Send
DO sendmail( SELECT * Request_Email_Send ) MODIFYS SQL DATA IN ( Email_Send_Result ) ;

CREATE TABLE Email_Send_Result (

    Request_ID INTEGER NOT NULL PRIMARY KEY
,     Email_Sent_OK BOOLEAN NOT NULL
,    Return_Code CHAR(3) NOT NULL

Now to (try to) send 100 emails, you insert 100 requests into Request_Email_Send,
rather than allow functions that have (either internal or external) side effects into SQL. But then you (might) need to understand that logical transactions themselves are a really bad idea to see why the SQL solution is bad....

> 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, I doubt that academia is particularly interested in fixing legacy bugs (not least because SQL is not really fixable - we need to start again afresh). Also, some would say that they are getting to be as much 'customer driven' as industry. The big problem is possibly that very few are properly educated, neither the customers (so they don't ask for correctness), industry (so they don't know how to deliver it) nor even some of academia (who have forgotten that correctness is their raisin-de-etra).

> 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.

Oh what we could do if we had no money to earn...

> My only salvation is the firm knowledge that those who break the model
> bad, shall be punished with maintenance of it for ever.

>

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