Re: Fabian Pascal and RDBMS deficiencies in fully implementing

From: Aaron Bingham <bingham(at)cenix-bioscience(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: dananrg(at)yahoo(dot)com, pgsql-general(at)postgresql(dot)org
Subject: Re: Fabian Pascal and RDBMS deficiencies in fully implementing
Date: 2006-06-12 09:08:55
Message-ID: 448D2F27.4080000@cenix-bioscience.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

David Fetter wrote:

>On Fri, Jun 09, 2006 at 03:55:04PM +0200, Aaron Bingham wrote:
>
>
>>dananrg(at)yahoo(dot)com wrote:
>>
>>
>>>I'm reading, and enjoying immensely, Fabial Pascal's book "Practical Issues in Database Management."
>>>
>>>
>
>If you're interested in the theory of RDBMSs, you can start with the papers on Leonid Libkin's page and the books and papers they reference. :)
>
>http://www.cs.toronto.edu/~libkin/publ.html
>
>
Thanks for the pointer, I will look into it later.

>>I also found this book very useful when I first started doing serious database work. For a more thorough treatment of many of these issues, see An Introduction to Database Systems by Chris Date. The latter book is so full of detail that it is sometimes hard to follow,
>>
>>
>It certainly has an elaborate and well-thought-out system of ideas. As an empiricist, I find it crucially important that despite decades of whining about it, no one has come up with an actual *computer* system which implements this /gedankenexperiment/.
>
>
Whether or not there will ever by an implementation of their definition
of the RM, their ideas provide useful guidance in designing real-world
databases today. The lack of an implementation of this RM is
unfortunate, but there are many possible explanations for this lack
other than faults in the theory itself. The theory _could_ be flawed,
of course, but I have not seen sufficient evidence to support that
conclusion.

>>but it's worth the effort.
>>
>>
>Why? There are much more entertaining cranks out there if crank study is your thing.
>
>
I'm not at all into crank study. I'm interested in basing design
decisions on a solid foundation, grounded in logic.

"An Introduction to Database Systems" is not a thorough exposition of
relational theory, as you seem to imply, but an _introduction_ to
database fundamentals and the application thereof to SQL-DBMSs. Were
you thinking of "The Third Manifesto" by Date and Darwen?

>>>Though I've just gotten started with the book, he seems to be saying that modern RDBMSs aren't as faithful to relational theory as they ought to be, and that this has many *practical* consequences, e.g. lack of functionality.
>>>
>>>Given that PostgreSQL is open source, it seems a more likely candidate for addressing Pascal's concerns. At least the potential is there.
>>>
>>>
>>Although some DBMSs have invented new ways to break the relational model, the fundamental problems are in SQL.
>>
>>
>
>Um, no. As I'll demonstrate below, it's the model that's broken and SQL that got it right.
>
>
I'm unconvinced. See below.

>>No DBMS based on SQL is going to be able to support RM correctly.
>>
>>
>
>Aha! I spy, with my little eye, a fanboy.
>
I may have come across as over-enthusiastic late on Friday afternoon; I
was attempting to counter over-enthusiastic claims in the other
direction. I find your choice of words insulting, but I won't hold it
against you.

I appreciate Date and Pascal's work because it is well reasoned and
grounded in mathematics and logic. I do not consider their work final
in any way. They themselves are quick to acknowledge gaps in their
understanding. I have not seen a better conceptual framework for
thinking about databases. If I were presented with one, I would not
cling to Date's or Pascal's views.

>You have to be a bit of a theory wonk to call Date's stuff "RM." You seem to be implying here
>that Date's "RM" is somehow more desirable than what SQL actually provides. To be more desirable, I don't think it's unreasonable to say that it should be more powerful in some essential way.
>
>
We were discussing Fabian Pascal's book. His book is based on his
definition of "RM", which is largely similar to (though not identical
with) Date's. My above claim applies to "RM" as defined by Date or
Pascal, not some other "RM". If you could point me to alternate
definitions of "RM" which are not in conflict with SQL, I would be
curious to see them.; a better framework for thinking about SQL
databases would be invaluable.

>In SQL, you can do this (this example condensed from Libkin's
>"Expressive Power of SQL" on the page above):
>
>SELECT
> (SELECT count(*) FROM table_1) <
> (SELECT count(*) FROM table_2)
> AS "Can't compare cardinalities in first order logic";
>
>Note the name of the output column. It's important and true, as you
>can verify if you care to do your homework on foundations of
>mathematics. Relational algebra is a subset of first-order logic
><http://en.wikipedia.org/wiki/Relational_algebra>, and as a direct
>consequence, you can't do this simple but interesting thing with it.
>
>
I must be missing something important. What aspect of the above query
is supposedly impossible in relational algebra and/or relational calculus?

>What say we just stop right there and call Date's Relational Model
>what it is: a silly edifice built atop wrong premises.
>
>
I'm unwilling to accept that claim without better evidence.

Regards,

--
--------------------------------------------------------------------
Aaron Bingham
Senior Software Engineer
Cenix BioScience GmbH
--------------------------------------------------------------------

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Gregory S. Williamson 2006-06-12 09:27:24 Re: Help with storing spatial (map coordinates) data?
Previous Message Greg 2006-06-12 08:57:49 Best security practices for installing pgSQL with my software

Browse pgsql-hackers by date

  From Date Subject
Next Message Aaron Bingham 2006-06-12 09:46:46 Re: Fabian Pascal and RDBMS deficiencies in fully implementing
Previous Message Mark Kirkwood 2006-06-12 05:21:19 Re: TODO: Add pg_get_acldef(), pg_get_typedefault(),