Trent Shipley wrote:
On Tuesday 2006-06-13 09:26, David Fetter wrote:
On Tue, Jun 13, 2006 at 09:18:17AM -0600, Scott Ribe wrote:
To hold it up as any kind of paradigm is really misinformed.
SQL had something that relational algebra/relational calculus did not
have, which is that somebody
On Tue, Jun 13, 2006 at 05:23:56PM -0400, Christopher Browne wrote:
[3]
http://www.intelligententerprise.com/010327/celko_online.jhtml;jsessionid=NDIHEWXGL4TNKQSNDBNSKHSCJUMEKJVN
The sample problem in [3] is one that shows pretty nicely a
significant SQL weakness; it's very painful to
kleptog@svana.org (Martijn van Oosterhout) writes:
On Tue, Jun 13, 2006 at 05:23:56PM -0400, Christopher Browne wrote:
[3]
http://www.intelligententerprise.com/010327/celko_online.jhtml;jsessionid=NDIHEWXGL4TNKQSNDBNSKHSCJUMEKJVN
The sample problem in [3] is one that shows pretty nicely
What say we just stop right there and call Date's Relational Model
what it is: a silly edifice built atop wrong premises.
SQL was a quick and dirty hack (Systems R and R* needed some way to
interface with data) with multiple deficiencies recognized and documented
right within the very first
On Tue, Jun 13, 2006 at 09:18:17AM -0600, Scott Ribe wrote:
What say we just stop right there and call Date's Relational Model
what it is: a silly edifice built atop wrong premises.
SQL was a quick and dirty hack (Systems R and R* needed some way to
interface with data) with multiple
Now, there's another thing that makes it amazingly hard to displace:
imagining what would be better *enough* to justify the many millions of
people-years and even more billions of dollars needed to move away from
it. Despite Date's many whines over the decades, his still-vaporware
Relational
On 6/13/06, David Fetter [EMAIL PROTECTED] wrote:
SQL was a quick and dirty hack (Systems R and R* needed some way to
interface with data) with multiple deficiencies recognized and
documented right within the very first paper by its own authors.
Perfection isn't a human attribute. There
On Tue, Jun 13, 2006 at 12:51:57PM -0400, Merlin Moncure wrote:
On 6/13/06, David Fetter [EMAIL PROTECTED] wrote:
SQL was a quick and dirty hack (Systems R and R* needed some way
to interface with data) with multiple deficiencies recognized and
documented right within the very first paper
2) Re: still-vaporware Relational Model- the relational model is a
mathematical model for data representation. Your comment makes as much
sense as claiming that Newtonian physics is vaporware.
If we're discussing the luminiferous aether, then, yes, vaporware
seems /somewhat/ appropriate.
David Fetter wrote:
On Tue, Jun 13, 2006 at 12:51:57PM -0400, Merlin Moncure wrote:
On 6/13/06, David Fetter [EMAIL PROTECTED] wrote:
SQL was a quick and dirty hack...
If there are better alternatives, they will need to show some
real-world attributes, not mathematically-inspired fantasies,
Ron Mayer [EMAIL PROTECTED] wrote:
David Fetter wrote:
the terse mathematical notation commonly used...
Again, if you have a piece of software you can point to that does
this
thing, please do so.
I seriously doubt it follows Date or Pascal religiously, but
it does have a convenient and
On Tuesday 2006-06-13 09:26, David Fetter wrote:
On Tue, Jun 13, 2006 at 09:18:17AM -0600, Scott Ribe wrote:
What say we just stop right there and call Date's Relational Model
what it is: a silly edifice built atop wrong premises.
SQL was a quick and dirty hack (Systems R and R* needed
David Fetter wrote:
On Fri, Jun 09, 2006 at 03:55:04PM +0200, Aaron Bingham wrote:
[EMAIL PROTECTED] 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
Aaron Bingham wrote:
David Fetter wrote:
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
or not this value.
Alejandro Michelin Salomon
Porto Alegre
Brasil
---Mensagem original-
--De: [EMAIL PROTECTED]
--[mailto:[EMAIL PROTECTED] Em nome de A.M.
--Enviada em: sexta-feira, 9 de junho de 2006 13:01
--Para: Postgres general mailing list
--Assunto: Re: [GENERAL] Fabian Pascal and RDBMS
* Roy Souther:
In what way could a database like PostgreSQL not be faithful to
relational theory? Does he give any explanation as to what that means?
My guess: In SQL (and in PostgreSQL as a result), relations aren't
sets, aren't first-class, and the underlying logic is not Boolean.
On 6/8/06, Chris Browne [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (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.
On 8 Jun 2006 05:21:07 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I'm reading, and enjoying immensely, Fabial Pascal's book Practical
Issues in Database Management.
Some questions:
1) Is PostgreSQL more faithful to relational theory? If so, do you find
yourself using the additional
On Sun, Jun 11, 2006 at 11:03:57AM -0400, Merlin Moncure wrote:
On 6/8/06, Chris Browne [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (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
Lots of great conversation here. Thanks to all for participating.
David, you wrote:
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.
I can't speak to that statement directly.
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
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
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.
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, [EMAIL PROTECTED] wrote:
on bag theory[1] and 3-value logic[2]. Until they come up
# [EMAIL PROTECTED] / 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
Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 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
[EMAIL PROTECTED] 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
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.
On Fri, June 9, 2006
On Fri, Jun 09, 2006 at 07:09:12AM -0400, Agent M wrote:
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.
At this point you could start a whole philosophical
On Fri, Jun 09, 2006 at 03:55:04PM +0200, Aaron Bingham wrote:
[EMAIL PROTECTED] 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
On Fri, Jun 09, 2006 at 05:20:46PM +0200, Martijn van Oosterhout wrote:
On Fri, Jun 09, 2006 at 07:09:12AM -0400, Agent M wrote:
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
On Fri, June 9, 2006 11:45 am, David Fetter wrote:
On Fri, Jun 09, 2006 at 05:20:46PM +0200, Martijn van Oosterhout wrote:
On Fri, Jun 09, 2006 at 07:09:12AM -0400, Agent M wrote:
Well, the Date argument against NULLs (and he never endorsed them,
or so he claims) is that they are not data-
Yes, and all SQL products worth their salt include some languages to
provide iteration and other processing that SQL can't do or doesn't do
well. Why must the rules be different for a truly relational db. (see
http://dbappbuilder.sourceforge.net/Rel.html)
I may get interested if some actual
On Fri, Jun 09, 2006 at 12:29:59PM -0400, A.M. wrote:
Yes, and all SQL products worth their salt include some languages
to provide iteration and other processing that SQL can't do or
doesn't do well. Why must the rules be different for a truly
relational db. (see
On Fri, Jun 09, 2006 at 12:01:07PM -0400, A.M. wrote:
So you should normalize and add relations to represent the state
adequately. NULL doesn't give you enough information anyway- does NULL in
a birthday header mean no birthday, n/a (a business doesn't have a
birthday), not born yet, etc...
On Friday 09 June 2006 12:39, David Fetter wrote:
On Fri, Jun 09, 2006 at 12:29:59PM -0400, A.M. wrote:
Yes, and all SQL products worth their salt include some languages
to provide iteration and other processing that SQL can't do or
doesn't do well. Why must the rules be different for a
On Fri, Jun 09, 2006 at 03:18:54PM -0400, Robert Treat wrote:
On Friday 09 June 2006 12:39, David Fetter wrote:
On Fri, Jun 09, 2006 at 12:29:59PM -0400, A.M. wrote:
Yes, and all SQL products worth their salt include some languages
to provide iteration and other processing that SQL
On Friday 2006-06-09 09:50, Martijn van Oosterhout wrote:
On Fri, Jun 09, 2006 at 12:01:07PM -0400, A.M. wrote:
So you should normalize and add relations to represent the state
adequately. NULL doesn't give you enough information anyway- does NULL in
a birthday header mean no birthday, n/a
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,
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
On Thu, 2006-06-08 at 07:21, [EMAIL PROTECTED] 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
In the last exciting episode, [EMAIL PROTECTED] 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
[EMAIL PROTECTED] (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
On Thu, 2006-06-08 at 16:17, Chris Browne wrote:
[EMAIL PROTECTED] (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.
On Thu, Jun 08, 2006 at 05:21:07AM -0700, [EMAIL PROTECTED] 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
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
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
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
On Thursday 2006-06-08 15:14, David Fetter wrote:
On Thu, Jun 08, 2006 at 05:21:07AM -0700, [EMAIL PROTECTED] 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
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, [EMAIL PROTECTED] wrote:
on bag theory[1] and 3-value logic[2]. Until they come up with a
testable system, or Hell freezes over,
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Trent Shipley)
wrote:
On Thursday 2006-06-08 15:14, David Fetter wrote:
On Thu, Jun 08, 2006 at 05:21:07AM -0700, [EMAIL PROTECTED] wrote:
on bag theory[1] and 3-value logic[2]. Until they come up with a
testable system, or Hell
50 matches
Mail list logo
