Re: The MySQL/PHP pair

"Dan" <guntermann_at_verizon.com> wrote in message news:iLkid.797$vM2.633_at_trnddc09...

> Oh really?
>
> Codd wrote: "A relational database is a time-varying collection of data,
all
> of which can be accessed and updated as if they were organized as a
> collection of time-varying tabular (nonhierarchic) relations of assorted
> degrees defined on a given set of simple domains." (p. 399).
>
> Concerning domains, he wrote:
> "A domain is a set of values of similar type: for example, all possible
part
> serial numbers for a given inventory or all possible dates for the class
of
> events being recorded. A domain is <italics>simple</italics> if all of
its
> values are atomic (nondecomposable by the database management system)."
>
> About the relational model he wrote:
> "The relational model consists of
> (1) a collection of time-varying tabular relations (with properties cited
> above - note especially the keys and domains);
> (2) the insert-update-delete rules (Rules 1 and 2 cited above);
> (3) the relational algebra describedin Sections 2.2 and 2.3 below.
>
> Closely associated with the relational model are various decomposition
> concepts which are semantic in nature (being time-invariant properties of
> time-varying relations). Examples of such concepts are nonloss (natural)
> joins and functional dependencies [6], multivalued dependencies [10,44],
and
> normal forms. (p. 400)."
>
> References:
> Codd, E.F. (1979). Extending the database relational model to capture
more
> meaning. ACM Transactions on Database Systems (TODS), 4:(4). [Online]
> Available at the ACM Digital Library at http://www.acm.org.

Thanks for the above. Given these quotes, what I'm really confused about is this:

Where do you and I disagree?

> >
> If you are talking about queryable logical elements, I am still convinced
> that Paul is absolutely right. There is a distinction between the
> relational model/relational engine and the type system. Types can be as
> complex as you want, nary the relational engine the wiser. It will still
> think of any type value as 1NF.

>
> Four people who are chummy in a usenet group doesn't necessarily
constitute
> absolute justification or agreement. Sorry.

Agasin, where do you and I differ?

>
> [snip]
> >
> > 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 have not studied that at all, I'll
admit,
> > but I have something else to counter questions of practicality -- a
system
> > that works (it would fit the def of "legacy" given by Gene in another
> > thread). There is a query language that goes by many different names
(one
> > for each implementation of the Nelson-Pick model) that successfully
> > queries
> > nested structures to a depth of n levels (n differs a bit but figure
only
> > 3)
> > and that depth of nesting is just about what the human brain uses when
> > forming statements (predicates), I'll claim. So, is it practical to
leave
> > the property formerly known as 1NF in the dust -- yes, it was practical
> > before 1NF was born and it is practical today (dare I mention XML?)
> >
> Or how about functions, like you've proposed before?
>
> "Q: A data model in which functions play a central role appears to have
the
> advantage of making algorithms and data more interchangeable. Why not
> replace n-ary relations of the relational model by functions (some or all
of
> which may be set valued)?
>
> A1: If you are trying to convert the relational model into a model for
> describing the various logical and physical data structures that are now
in
> use, this might be an appropriate step to take.

I agreed with the above, except for the terminology:

Here's how I would have put it:

A1: If you are trying to replace the relational model with a model for describing the various logical and physical data structures that are now in use, this might be an appropriate step to take.

> > 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.
>
> Then use those as a basis for a data model. If these are sufficient, then
> use them as a starting point, independent of what most accept as the
> relational model. Let's see how they stack up when you are done.

Agreed, with one proviso: Musings on how they will stack up are not forbidden, pending the completion of such a project. Received on Thu Nov 04 2004 - 15:29:25 CET