Re: The MySQL/PHP pair

"Laconic2" <laconic2_at_comcast.net> wrote in message news:iYSdncLx4ofSrBfcRVn-ow_at_comcast.com...
>
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message
> news:cmaqq2$a1h$1_at_news.netins.net...
> > If you go back to the original Codd papers and look at the definitions
of
> > relation and normalization, you can see that, as Codd acknowledges,
there
> is
> > nothing in the mathematics that prohibits relations (or functions, bags,
> > sets, ...) as elements of relations.
>
> Agreed.
>
> > The rationale for 1NF was to simplify
> > the operations at least at the start of our work with data in relations.
> > This was not a mathematical argument, but a pragmatic one.
>
> Agreed.
>
> It's important to realize that, at the time of the 1970 paper, no
relational
> database system had been built.
> The atomic values limitation, as a pragmatic one, allowed a simplified
> version of the equality test to be used:
>
> Compare the representation, bit by bit. If there are any bits that have
> different values in the two representations, or if the two representations
> have a different number of bits, then they are different representations.
> If you take the additional assumption that different representations
cannot
> represent the same value, then you have a simple test for equality that
the
> relational engine can carry out, even without understanding the "meaning"
> of the underlying type. This means the relational engine can do
equijoins,
> even when it doesn't know what it's joining, except to know the
> representation and the type.
>
> > Relational
> > theorists have now ditched 1NF (by redefining it as being a necessary
> > property of a relation and not requiring atomic values in relations).
So,
> > neither relational theorists nor those who were already working with
> non-1NF
> > data formats require data in what used to be 1NF form.
>
> I have a quible with this. While Date&Darwen and those who agree with
them
> have done what you describe above, I think it's a stretch to say that
> "relational theorists" are in general consensus about this.

I was basing this statement on SQL-99 as much as Date & Darwin. Given that nested structures are now supported by the current SQL standard, even though not widely used, I figure that at least gives some credibility to nested relations. I do realize there is little consensus on whether or how to employ such features.

> And, among "relational practitioners" the older definition is still in
> widespread use. And, among teachers of relational database subject
matter,
> the old definition of 1NF is still taught more often than not.

Yes, and this one reason to up the visibility re 1NF.

>
> >
>
> > If this does not prove to you that there is no mathematical basis for
the
> > old 1NF, start where I did -- with the original definitions and
papers --
> > and see if you can find such a basis for the old version of 1NF
>
> (I REALLY,
> > REALLY WISH THEY HAD NOT CHANGED THE DEF DRASTICALLY, BUT HAD DITCHED IT
> > ALTOGETHER AND USED NEW TERMS!).
>
> Strongly Agreed.
>
> > What type of proof would you accept -- I could lay out the original def
of
> > relation and of 1NF and the original arguement for 1NF and show that
while
> > the def of "relation" is mathematical, the rational for 1NF is not. I
can
> > point to the statements in the prior works of Date (BR -- before the
> > redefinition) where he makes jumps that are not mathematical in the
> > discussion of 1NF. But it would be easier if you would point me to the
> > discourse that you think has mathematical rigor and I can show you where
> the
> > mathematics stops and non-rigorous statements are included.
>
> I think the discussion is stalled at thispoint because people are
requiring
> a formal mathematic proof of two things that are not inherently
> mathematical: the definition of terms and the history of ideas in
> relational data modeling.

Yes -- I wasn't quite able to figure out how one proves mathematically something that is not.

>
> > Yes, there are practical issues and the issue of the query language is
the
> > one that holds the most water -- when do we move from 1st to 2nd order
> > predicate logic, for example.
>
> I think the one area of near universal agreement among RDM theorists is
that
> a universal data sublanguage is needed, and that SQL isn't it.

SQL still has its fans, but with nothing else on the horizon, I think XQuery could be where we are headed. I'm not as sad about that as others are since it does handle more of what I'm looking for than does SQL. It isn't likely to make too many DBAs or DB professionals happy, however.

> This is where my practice diverges from the position of theorists: I
worked
> with SQL, and my attitude towards it is that it was "good enough for
> practical work" in spite of its flaws. I'll admit that I haven't studied
> any of the proposed replacements at all, and that I don't intend to until
> one of them emerges as a clear "lingua franca". That's not to say that I
> recommend my path to others. Practical people are needed, and theorists
are
> needed.

And my experience, as mentioned before, is different in that I have seen a query language that works with not-exactly-relational structures (non-1NF) that is easier to use in many respects than is SQL.

> > Once again, IBM has two such databases in their porfolio -- UniVerse &
> > UniData and there are many others out there -- Revelation, jBASE, D3,
> > mvBASE, UniVision, mvEnterprise, Reality.
>
> I think the following questions are fair, given your prior posts on this
> subject:
>
> In what ways are Universe&Unidata similar to Pick? In what ways are they
> different?

UniVerse & UniData are two implementations of the same data model as Pick. Both were in litigation with Pick at various times in history and UniVerse ended up having to pay Pick while UniData did not. They were both implementations of the Prime Information implementation of the Pick model which did not have to pay a royalty to Pick. I studied the history of Pick and related products a few years ago and prepared a poster showing three families of products
http://www.tincat-group.com/images/MVFamilyTreeColor.pdf

The right hand side of the poster has a list of the names of the query language that is, in some ways, better than SQL (at least from a user perspective -- it lacks features such as update and isn't perfect by any means, but very easy to use). These are all closer to being the same language than are flavors of SQL even though no industry standard was in play (or maybe BECAUSE no industry standard was applicable?). This entire industry -- a multi-billion dollar a year database industry still today, as I understand it -- is almost invisible to those who discuss the IT industry. It has been pronounced dead many times.

Cheers! --dawn Received on Fri Nov 05 2004 - 01:54:58 CET