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
--------------------------------------------------------------------
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 |
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(), |