Re: Lucid statement of the MV vs RM position?

JOG wrote:
> dawn wrote:
> > Jan Hidders wrote:
> > > dawn wrote:
> > > > Jan Hidders wrote:
> > > > > dawn wrote:
> > > > > >
> > > > > > Well, there's more than 30 years of production apps out there running
> > > > > > flavors of MUMPS, PICK, and others from which the jury could gather
> > > > > > data.
> > > > >
> > > > > They already have done so, and they already know why they work
> > > > > efficiently under certain circumstances, and under which circumstances
> > > > > they have problems.
> > > >
> > > > I've tried to find those "they" people to see what they have found out.
> > > > Can you point to one study out there that compares Pick with SQL-based
> > > > products? What is out there that compares any non-SQL (or SQL as a
> > > > second language) databases with SQL DBMS's without using SQL against
> > > > the non-SQL database? I'm apparently doing a lousy job of searching.
> > > > I'm not looking for theory on this one, but actual studies of real
> > > > software solutions. It does seem like there would be such, but I'm not
> > > > finding 'em.
> >
> > > I don't know any, nor do I expect something like that to exist. Such
> > > comparisons are difficult because of several reasons. The claims of the
> > > RM are mainly wrt. the functioning of an IT department as a whole
> > > within a certain type of context. That is hard to recreate in an
> > > experiment.
> >
> > OK, so you told me the jury was out regarding modeling and implementing
> > with non-1NF data (or something like that); then I told you that there
> > are production systems out there, if the jury really wanted to know;
> > then you said they have already gathered data; then I tried to ask
> > "where is it?"; and you said "I don't know any, nor do I expect
> > something like that to exist."
> >
> > So, I think we talked past each other on that one. If RVAs and other
> > non-1NF structures are now accepted in theory and implemented in
> > practice, then when should they be used?

>

>

There are many differing definitions of 1NF, but the traditional one is that it is equal to what Codd termed "normalized" which he discusses in the 1970 paper. That is the only definition I can find that has been popularized enough for most practitioners to have in mind when someone mentions 1NF. I know you read my "Is Codd Dead?" blog entry, Jim, but to clarify, it loosely means "no repeating groups" or what Cood called "nonsimple domains." I recognize this is not precise, but it is the thinking behind the origins of SQL, the ramifications of which are still with us big time.

There are now some (Date, for example) who have redefined 1NF to have no real meaning. If something is a relation, it is in 1NF by this definition IIRC. That is not the 1NF to which I am referring.

> By definition, mathematical relations may not have variable
> cardinalities across tuples and hence (but only as a consequence)
> applying 1NF means that each field must be guaranteed to occur but
> once.

>

This is only true if one has redefined 1NF to make it true. This is not the case with the original definitions, which is why SQL (which might be a flawed implementation, but was based on the RM as it was then defined) did not include RVAs (SQL '92 on which ODBC is based does not include them, for example).

> as one
> can still form acceptable tuples with them. Currently one has to
> manipulate these user defined types externally as the tools aren't
> really there to do otherwise (apart from strings and date types).
>
> Is this not how you see it? All best, J.

No, those are not the definitions that I am using. I'm not doing any fancy footwork with the original definitions. Since I work with what are called NF2 databases (or NF^2), which stands for Non-First Normal Form, I am using the definition of 1NF that prompts the NF2 designation. If you have a better term for the-approach-formerly-known-as-1NF, let me know and I'll try to incorporate it where 1NF might otherwise be confusing.

Cheers! --dawn Received on Tue May 02 2006 - 02:21:44 CEST