Fabian Pascal and RDBMS deficiencies in fully implementing the relational model
I'm reading, and enjoying immensely, Fabial Pascal's book "Practical
Issues in Database Management."
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.
Some questions:
1) Is PostgreSQL more faithful to relational theory? If so, do you find
yourself using the additional functionality afforded by this? e.g. does
it really matter to what you do in your daily work.
2) If PostgreSQL is *not* significantly more faithful to relational
theory than commercial RDBMSs, is it at least on the road to becoming
more faithful?
3) If PostgreSQL is not on the road to becoming more faithful to
relational theory and purity, why not? Is it due to the fact that
various SQL standards are themselves not fully faithful to relational
theory, and most RDBMSs have as a primary design goal to be faithful to
standards (which Pascal implies *are* relationally deficient)?
4) Which database, commercial or non-commercial, is most faithful to
relational theory itself, or is headed in that direction the quickest?
Dana
In what way could a database like PostgreSQL not be "faithful to
relational theory"? Does he give any explanation as to what that means?
Some people mistake the word relational for the meaning of
normalization, but they do not have the same meaning. If Fabial is
mistaking relational for normalization then that would make sense
because there is nothing to force the use of normalization.
On Thu, 2006-06-08 at 05:21 -0700, dananrg@yahoo.com wrote:
I'm reading, and enjoying immensely, Fabial Pascal's book "Practical
Issues in Database Management."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.Some questions:
1) Is PostgreSQL more faithful to relational theory? If so, do you find
yourself using the additional functionality afforded by this? e.g. does
it really matter to what you do in your daily work.2) If PostgreSQL is *not* significantly more faithful to relational
theory than commercial RDBMSs, is it at least on the road to becoming
more faithful?3) If PostgreSQL is not on the road to becoming more faithful to
relational theory and purity, why not? Is it due to the fact that
various SQL standards are themselves not fully faithful to relational
theory, and most RDBMSs have as a primary design goal to be faithful to
standards (which Pascal implies *are* relationally deficient)?4) Which database, commercial or non-commercial, is most faithful to
relational theory itself, or is headed in that direction the quickest?Dana
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
Royce Souther
www.SiliconTao.com
Let Open Source help your business move beyond.
For security this message is digitally authenticated by GnuPG.
On Thu, 2006-06-08 at 07:21, dananrg@yahoo.com wrote:
I'm reading, and enjoying immensely, Fabial Pascal's book "Practical
Issues in Database Management."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.
I generally find the arguments that modern RDBMSes aren't faithful to
relational theory to be much like the old arguments about how many
angels could dance on the head of a pin.
The single most commonly trotted out one is that in relational and set
theory, duplicates are not allowed, but modern RDBMS systems allow
duplicates, unless you design your schema to reject duplicates on
purpose.
While it would sometimes be useful to have my database automatically
declare all tables to have a unique index across every field in a table,
I know that performance wise this could be a disaster for some data
sets, and often it would have no real value. Not that they don't have a
valid argument, I just think it's a kind of petty argument.
The other arguments that show up generally have to do with having the
ability to get the same data results in more than one way (i.e. a
non-deterministic methodology) which other query languages seemed to
have solved in the past. OTOH, PostgreSQL descended from a database
that used the QUEL query language, and it seems a bit hard to find other
QUEL databases. SQL may not be perfect, but it is fairly ubiquitous,
and that makes porting to or from one SQL db to another moderately easy.
To me, the real argument is, "Is SQL so lacking that it should be
replaced". In what REAL measurable ways is SQL lacking so badly we
should toss it and start over? It's not perfect, that's for sure. But
what's the investment on starting over, and the possible traction of a
non-SQL database in a largely SQL driven market?
In the last exciting episode, dananrg@yahoo.com wrote:
I'm reading, and enjoying immensely, Fabial Pascal's book "Practical
Issues in Database Management."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.Some questions:
1) Is PostgreSQL more faithful to relational theory? If so, do you find
yourself using the additional functionality afforded by this? e.g. does
it really matter to what you do in your daily work.
PostgreSQL's fidelity is more to the SQL standards than to relational
theory, per se, but there are places where it does "play better" than
some of its competitors with regard to relational behaviour.
Oracle, for instance, has the trouble that it does not generally
perceive NULL as being distinct from empty strings.
2) If PostgreSQL is *not* significantly more faithful to relational
theory than commercial RDBMSs, is it at least on the road to
becoming more faithful?
It's probably fairer to say that it isn't on any road to become "less
faithful."
The tendancy for products like Oracle and DB2 has been to hearken down
roads with XML on the signs, and to lose rational behaviour on that
basis.
3) If PostgreSQL is not on the road to becoming more faithful to
relational theory and purity, why not? Is it due to the fact that
various SQL standards are themselves not fully faithful to relational
theory, and most RDBMSs have as a primary design goal to be faithful to
standards (which Pascal implies *are* relationally deficient)?
There are two big bits of trouble to SQL:
1. NULL is a problem (where there isn't any choice of implementation
strategies that *won't* lead to considerable pain), which is why the
would-be relational successor, Tutorial D, rejects having NULL
altogether.
2. Features get added to SQL standards without much regard to
fidelity to a relational model. Often, features get added because
they seem cool, and because Microsoft or IBM figure the features can
get them some sales. That doesn't guarantee fidelity to much of
anything :-(.
4) Which database, commercial or non-commercial, is most faithful to
relational theory itself, or is headed in that direction the
quickest?
The product that appears to have greatest fidelity to SQL standards is
Mimer SQL. That's not quite the same thing as fidelity to relational
theory, of course.
One of the interesting edges, with PostgreSQL, is the whole
"object/relational" side of it. Darwen and Date were highly critical
of O/R; they felt that "doing relational right" was generally a better
thing.
I'd argue that with the extensible type system, PostgreSQL does parts
of this quite right.
The place where there is controversy is in how PostgreSQL should deal
with things like inheritance, when inheriting attributes from a table,
and the lack of agreement seems to me to demonstrate that there's not
any particular will to continue down the "O/R dogma" road...
--
let name="cbbrowne" and tld="gmail.com" in name ^ "@" ^ tld;;
http://linuxdatabases.info/info/nonrdbms.html
"I will not send lard through the mail" ^ 100 -- Bart Simpson
smarlowe@g2switchworks.com (Scott Marlowe) writes:
To me, the real argument is, "Is SQL so lacking that it should be
replaced". In what REAL measurable ways is SQL lacking so badly we
should toss it and start over? It's not perfect, that's for sure.
But what's the investment on starting over, and the possible
traction of a non-SQL database in a largely SQL driven market?
The only visible alternative, at this point, is Tutorial D, and it
doesn't particularly excite me...
--
"cbbrowne","@","ntlug.org"
http://www3.sympatico.ca/cbbrowne/languages.html
A mathematician is a machine for converting caffeine into theorems.
On Thu, 2006-06-08 at 16:17, Chris Browne wrote:
smarlowe@g2switchworks.com (Scott Marlowe) writes:
To me, the real argument is, "Is SQL so lacking that it should be
replaced". In what REAL measurable ways is SQL lacking so badly we
should toss it and start over? It's not perfect, that's for sure.
But what's the investment on starting over, and the possible
traction of a non-SQL database in a largely SQL driven market?The only visible alternative, at this point, is Tutorial D, and it
doesn't particularly excite me...
On the other hand, it's nice to know it's dragged down by a moniker even
more awkward than PostgreSQL's!
Honestly, Tutorial D does not make me think database. It makes me think
Calculus help line.
On Thu, Jun 08, 2006 at 05:21:07AM -0700, dananrg@yahoo.com wrote:
I'm reading, and enjoying immensely, Fabial Pascal's book "Practical
Issues in Database Management."
Be aware that Pascal, along with Date and Darwen, are...how do I put
this gently...cranks. They've been getting more strident and
irrational as the decades go by.
Pascal, Date, and Darwen have been alleging for years, with increasing
shrillness, that DBMSs should be based on set theory and 2-value
logic. I say "alleging" because they have not backed up this idea
with any actual software that others could test. SQL DBMSs are based
on bag theory[1]Basically set theory with repetition of elements allowed. This in turn makes aggregates easy and natural to implement. and 3-value logic[2]A boolean value can take the values true, false and unknown.. Until they come up with a
testable system, or Hell freezes over, whichever comes first, Pascal's
book will make a good companion on your shelf to books on
Phlogiston[3]http://en.wikipedia.org/wiki/Phlogiston theory, or a decent doorstop, whichever you prefer.
Cheers,
D
[1]: Basically set theory with repetition of elements allowed. This in turn makes aggregates easy and natural to implement.
turn makes aggregates easy and natural to implement.
[2]: A boolean value can take the values true, false and unknown.
[3]: http://en.wikipedia.org/wiki/Phlogiston
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!
On Thu, 2006-06-08 at 17:14, David Fetter wrote:
Pascal, Date, and Darwen have been alleging for years, with increasing
shrillness, that DBMSs should be based on set theory and 2-value
logic. I say "alleging" because they have not backed up this idea
with any actual software that others could test. SQL DBMSs are based
on bag theory[1] and 3-value logic[2]. Until they come up with a
testable system, or Hell freezes over, whichever comes first, Pascal's
book will make a good companion on your shelf to books on
Phlogiston[3] theory, or a decent doorstop, whichever you prefer.
Now you're just being ridiculous.
Most of those books are nowhere near heavy enough to be a good door
stop.
And I don't know what your problem with Phlogiston is, it's a perfectly
cromulent thoery. (see
http://en.wikipedia.org/wiki/Cromulent#Cromulent)
On Thu, Jun 08, 2006 at 05:22:46PM -0500, Scott Marlowe wrote:
On Thu, 2006-06-08 at 17:14, David Fetter wrote:
Pascal, Date, and Darwen have been alleging for years, with
increasing shrillness, that DBMSs should be based on set theory
and 2-value logic. I say "alleging" because they have not backed
up this idea with any actual software that others could test. SQL
DBMSs are based on bag theory[1] and 3-value logic[2]. Until they
come up with a testable system, or Hell freezes over, whichever
comes first, Pascal's book will make a good companion on your
shelf to books on Phlogiston[3] theory, or a decent doorstop,
whichever you prefer.Now you're just being ridiculous.
Most of those books are nowhere near heavy enough to be a good door
stop.
I'm sorry I exaggerated here. You're right, of course. Most of them
would make only half-way decent doorstops. Date's latest from
O'Reilly isn't even that.
And I don't know what your problem with Phlogiston is, it's a
perfectly cromulent thoery. (see
http://en.wikipedia.org/wiki/Cromulent#Cromulent)
The Simpsons is almost enough to make me get a working TV and watch
Fox on it, but not quite :)
Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!
To balance the discussion, I would like to say that I thoroughly
enjoyed Date's latest "Database In Depth". It gave me a strong
foundation in relational theory and I can say that I think more about
my schema designs thanks to the advice in the text. Just because SQL
may allow something, doesn't make it good. If you don't use NULL, then
you don't come across 3-valued logic--problem solved.
Some Tutorial D notions really make sense; I would love to be able to
rely on every function returning a relation.
Everything is OK until he starts peddling TransRelational™ software...
On Jun 8, 2006, at 6:14 PM, David Fetter wrote:
On Thu, Jun 08, 2006 at 05:21:07AM -0700, dananrg@yahoo.com wrote:
I'm reading, and enjoying immensely, Fabial Pascal's book "Practical
Issues in Database Management."Be aware that Pascal, along with Date and Darwen, are...how do I put
this gently...cranks. They've been getting more strident and
irrational as the decades go by.Pascal, Date, and Darwen have been alleging for years, with increasing
shrillness, that DBMSs should be based on set theory and 2-value
logic. I say "alleging" because they have not backed up this idea
with any actual software that others could test. SQL DBMSs are based
on bag theory[1] and 3-value logic[2]. Until they come up with a
testable system, or Hell freezes over, whichever comes first, Pascal's
book will make a good companion on your shelf to books on
Phlogiston[3] theory, or a decent doorstop, whichever you prefer.Cheers,
D
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
AgentM
agentm@themactionfaction.com
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
On Thursday 2006-06-08 15:14, David Fetter wrote:
On Thu, Jun 08, 2006 at 05:21:07AM -0700, dananrg@yahoo.com wrote:
on bag theory[1] and 3-value logic[2]. Until they come up with a
testable system, or Hell freezes over, whichever comes first, Pascal's
book will make a good companion on your shelf to books on
Phlogiston[3] theory, or a decent doorstop, whichever you prefer.
I have encountered at least two commercial database products that declared
every column "NOT NULL". I have always assumed that this was defensive,
preventing stupid programmer mistakes.
I recall reading somewhere that Codd proposed multiple flavors of nullity.
Are there theoretical proposals for databases with logical systems having
more than three values?
On Thu, Jun 08, 2006 at 06:09:21PM -0700, Trent Shipley wrote:
On Thursday 2006-06-08 15:14, David Fetter wrote:
On Thu, Jun 08, 2006 at 05:21:07AM -0700, dananrg@yahoo.com wrote:
on bag theory[1] and 3-value logic[2]. Until they come up with a
testable system, or Hell freezes over, whichever comes first,
Pascal's book will make a good companion on your shelf to books on
Phlogiston[3] theory, or a decent doorstop, whichever you prefer.I have encountered at least two commercial database products that
declared every column "NOT NULL". I have always assumed that this
was defensive, preventing stupid programmer mistakes.
It's not that simple. If there are no NULLs allowed anywhere, that
means that you can't even have them as the output of a SELECT
statement, which means no OUTER JOINs. No repetitions means none
anywhere, which means that they can't be the output of a query either,
and makes it complicated at best to do aggregates. The whole thing is
just ridiculous on its face.
I recall reading somewhere that Codd proposed multiple flavors of
nullity. Are there theoretical proposals for databases with logical
systems having more than three values?
Codd proposed two different NULLs, if I recall right, and some people
have come up with tens of different meanings that NULL might have,
which leads to some major silliness wherein your "truth table" is a
grid that doesn't legibly fit on a piece of A4 paper.
Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!
A long time ago, in a galaxy far, far away, tshipley@deru.com (Trent Shipley) wrote:
On Thursday 2006-06-08 15:14, David Fetter wrote:
On Thu, Jun 08, 2006 at 05:21:07AM -0700, dananrg@yahoo.com wrote:
on bag theory[1] and 3-value logic[2]. Until they come up with a
testable system, or Hell freezes over, whichever comes first,
Pascal's book will make a good companion on your shelf to books on
Phlogiston[3] theory, or a decent doorstop, whichever you prefer.I have encountered at least two commercial database products that
declared every column "NOT NULL". I have always assumed that this
was defensive, preventing stupid programmer mistakes.I recall reading somewhere that Codd proposed multiple flavors of
nullity. Are there theoretical proposals for databases with logical
systems having more than three values?
Darwen did a paper where he described how you'd cope with not having
any nulls. It amounted to having a whole bunch of views that would
have a whole host of special indicator values to replace the multiple
meanings of NULL...
--
let name="cbbrowne" and tld="gmail.com" in String.concat "@" [name;tld];;
http://linuxdatabases.info/info/lisp.html
Including a destination in the CC list that will cause the recipients'
mailer to blow out is a good way to stifle dissent.
-- from the Symbolics Guidelines for Sending Mail
Agent M wrote:
If you don't use NULL, then you don't
come across 3-valued logic--problem solved.
So was does "SELECT sum(1) FROM dual WHERE false" return?
/Nis
Well, the Date argument against NULLs (and he never endorsed them, or
so he claims) is that they are not data- they represent the absence of
data- so why put non-data in a _data_base.
If you are asking yourself the question how you can have support
multiple meanings in a column, normalize. Then, baldness is just
another value and you don't have to guess if the hair color is unknown,
undefined, or missing.
On Jun 8, 2006, at 10:10 PM, Christopher Browne wrote:
A long time ago, in a galaxy far, far away, tshipley@deru.com (Trent
Shipley) wrote:On Thursday 2006-06-08 15:14, David Fetter wrote:
On Thu, Jun 08, 2006 at 05:21:07AM -0700, dananrg@yahoo.com wrote:
on bag theory[1] and 3-value logic[2]. Until they come up with a
testable system, or Hell freezes over, whichever comes first,
Pascal's book will make a good companion on your shelf to books on
Phlogiston[3] theory, or a decent doorstop, whichever you prefer.I have encountered at least two commercial database products that
declared every column "NOT NULL". I have always assumed that this
was defensive, preventing stupid programmer mistakes.I recall reading somewhere that Codd proposed multiple flavors of
nullity. Are there theoretical proposals for databases with logical
systems having more than three values?Darwen did a paper where he described how you'd cope with not having
any nulls. It amounted to having a whole bunch of views that would
have a whole host of special indicator values to replace the multiple
meanings of NULL...
--
let name="cbbrowne" and tld="gmail.com" in String.concat "@"
[name;tld];;
http://linuxdatabases.info/info/lisp.html
Including a destination in the CC list that will cause the recipients'
mailer to blow out is a good way to stifle dissent.
-- from the Symbolics Guidelines for Sending Mail---------------------------(end of
broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that
your
message can get through to the mailing list cleanly
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
AgentM
agentm@themactionfaction.com
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
On Jun 8, 2006, at 9:32 PM, David Fetter wrote:
On Thu, Jun 08, 2006 at 06:09:21PM -0700, Trent Shipley wrote:
On Thursday 2006-06-08 15:14, David Fetter wrote:
On Thu, Jun 08, 2006 at 05:21:07AM -0700, dananrg@yahoo.com wrote:
on bag theory[1] and 3-value logic[2]. Until they come up with a
testable system, or Hell freezes over, whichever comes first,
Pascal's book will make a good companion on your shelf to books on
Phlogiston[3] theory, or a decent doorstop, whichever you prefer.I have encountered at least two commercial database products that
declared every column "NOT NULL". I have always assumed that this
was defensive, preventing stupid programmer mistakes.It's not that simple. If there are no NULLs allowed anywhere, that
means that you can't even have them as the output of a SELECT
statement, which means no OUTER JOINs. No repetitions means none
anywhere, which means that they can't be the output of a query either,
and makes it complicated at best to do aggregates. The whole thing is
just ridiculous on its face.
Yes, no repetition. The point is that all functions should return
actual relations, so no ordering either. This makes it trivial to chain
the operations which is painful to do in SQL because you have to pay
attention to return types *and* whether or not the subquery returns one
or more rows or just one "value".
The OUTER JOIN stuff is a limitation of SQL. In the relational model,
there is no reason a column type cannot be a relation itself, however
SQL can't cope well with that. Aggregates can return relations as
header types so all the applicable tuples are returned. I have to do
that in PostgreSQL with arrays but there is no trivial way to convert
between arrays and a fake view or table or a VALUES() construct :-(
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
AgentM
agentm@themactionfaction.com
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
# nis@superlativ.dk / 2006-06-09 10:12:21 +0200:
Agent M wrote:
If you don't use NULL, then you don't
come across 3-valued logic--problem solved.So was does "SELECT sum(1) FROM dual WHERE false" return?
You stripped this:
Some Tutorial D notions really make sense; I would love to be able
to rely on every function returning a relation.
So your query would prolly return a table with one (INT) column,
but no rows.
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
dananrg@yahoo.com wrote:
I'm reading, and enjoying immensely, Fabial Pascal's book "Practical
Issues in Database Management."
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, but it's worth
the effort.
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. No DBMS based on SQL is
going to be able to support RM correctly.
Some questions:
1) Is PostgreSQL more faithful to relational theory? If so, do you find
yourself using the additional functionality afforded by this? e.g. does
it really matter to what you do in your daily work.
Within the limitations imposed by the SQL standard, PostgreSQL seems to
do about as well as could be expected, but falls short as all SQL DBMSs
must. For example, PostgreSQL allows NULLs and duplicate rows (there
are preventive measures against both of these but you have to be careful
to avoid them, and sometimes you can't). One feature of RM PostgreSQL
lacks are nested relations (a bad idea for base table design but useful
in query results).
Regards,
--
--------------------------------------------------------------------
Aaron Bingham
Senior Software Engineer
Cenix BioScience GmbH
--------------------------------------------------------------------
Roman Neuhauser wrote:
# nis@superlativ.dk / 2006-06-09 10:12:21 +0200:
Agent M wrote:
If you don't use NULL, then you don't
come across 3-valued logic--problem solved.So was does "SELECT sum(1) FROM dual WHERE false" return?
You stripped this:
Some Tutorial D notions really make sense; I would love to be able
to rely on every function returning a relation.
Yes. I didn't see its relevance to the claim that "if you don't use
null, you will not come across 3-valued logic". My point being that you
need to make sure that your queries don't generate them behind your back
either.
So your query would prolly return a table with one (INT) column,
but no rows.
Well, if you are not bound by the SQL standard and its mistakes, the
"obvious" return value would be one row, one column, containing 0.
/Nis
Also, Date mentions the notion that tables don't have to be mapped to
individual files. For example, if the types of queries are known in
advance, it could be possible to rearrange the data to be optimal for
those queries. Currently, tables are just big serialized arrays.
Show quoted text
On Fri, June 9, 2006 9:55 am, Aaron Bingham wrote:
dananrg@yahoo.com wrote:
I'm reading, and enjoying immensely, Fabial Pascal's book "Practical
Issues in Database Management."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, but it's worth
the effort.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. No DBMS based on SQL is going
to be able to support RM correctly.Some questions:
1) Is PostgreSQL more faithful to relational theory? If so, do you find
yourself using the additional functionality afforded by this? e.g.
does it really matter to what you do in your daily work.Within the limitations imposed by the SQL standard, PostgreSQL seems to
do about as well as could be expected, but falls short as all SQL DBMSs
must. For example, PostgreSQL allows NULLs and duplicate rows (there are
preventive measures against both of these but you have to be careful to
avoid them, and sometimes you can't). One feature of RM PostgreSQL lacks
are nested relations (a bad idea for base table design but useful in query
results).Regards,
--
--------------------------------------------------------------------
Aaron Bingham
Senior Software Engineer
Cenix BioScience GmbH
-----------------------------------------------------------------------------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
