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 with
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 pret
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
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
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 conv
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 fantasie
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.
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 fi
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
> 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
> Relati
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
> 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 pa
* 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.
--
his 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] Fa
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
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 th
On Fri, Jun 09, 2006 at 09:54:56AM -0700, [EMAIL PROTECTED] wrote:
> 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
> >i
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 ba
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 fu
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 sur
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. Indi
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 birthda
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 t
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 diff
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",
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 http://dbappbui
>> 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
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
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 pu
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
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 philosophic
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 9:55
[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 D
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 notio
# [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
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 wit
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. The
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
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,
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 ove
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 y
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 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 t
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 c
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 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
[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
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 th
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 th
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 normal
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,
51 matches
Mail list logo