Re: abstraction of table relationships

Your example reveals two things...:

1. First, that SQL is indeed a syntaxically redundant language to express logical concept of JOIN in a natural way...

Such limitation was clearly identified in Practical Issues in Data Management...On the specific concept of JOIN (only this one though), even some proprietary languages in Bullshit Multidimensional DB's such as Caché do better than SQL...For

Select * from Books natural join Authorship natural join

    Persons where PersonId = 'Steven King'; Select * from Books natural join Editorship natural join

    Persons where PersonId = 'John Doe';

would be syntaxically expressed as

Select * from Books --> Authorship --> Persons where PersonId = 'Steven King';
Select * from Books --> Editorship --> Persons where PersonId = 'John Doe';

2) Second your example reveals the importance for a relational language to *explicitely* declare pathes. A solution would be to answer that the expression should be expressed as

*Find ALL books written by 'Stephen King'*
*Find ALL books edited by 'John Doe'*

Therefore, Books, Authorship, Editorship and Person should be normalized as

Books: bookid
Books_writtenby: bookid, personid
Books_editedby: bookid, personid
Personid: personid

The two above queries could be expressed as

select * Books where bookid natural join (select bookid from Books_writtenby where Personid = 'Stephen King') select * Books where bookid natural join (select bookid from Books_editedby where Personid = 'John Doe')

considering a view defined on (select bookid from Books_written where Personid = 'Stephen King') and (select bookid from Books_edited where Personid = 'Stephen King')
the system should be able to conclude that *writtenby* and *editedby* are the hints that determine the pathes...Such deterministic approach would lead to soomething like..

select * from Books where Personid(writtenby) = 'Stephen King' select * from Books where Personid(editedby) = 'John Doe'

This is as far as you can go using SQL

3) the above example illustrate the incapability of SQL DBMS systems to support relation derivability

Both Books_writtenby and Books_editedby are relations that extract and restrict their tuples from the tuple domain defined by Books. If SQL could support domain derivability, it would be possible to write

select * from Books (writtenby) = 'Stephen King' select * from Books (editedby) = 'John Doe'

or

ALL Books writtenby 'Stephen King'
ALL Books editedby 'John Doe'

But as you can see this is not SQL anymore ...While your point was to attempt to debunk (rightfully, I admit), you have once more proved that SQL is lost cause to implement anything truly relational... Received on Thu Sep 07 2006 - 12:44:42 CEST