Re: Lucid statement of the MV vs RM position?
Date: 1 May 2006 19:52:03 -0700
Message-ID: <1146538323.477680.56290_at_v46g2000cwv.googlegroups.com>
dawn wrote:
> 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?
> >
> > I'm confused by this statement Dawn. My understanding is as follows:
> >
> > 1NF is definitional in that it is simply a case of saying that
> > "everything must be stored as tuples", allowing sets of such to form
> > relations.
>
> 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.
This take on 1NF has no "meaning" as such, but it does have practical consequences. And it is pretty much the version of 1NF that I described. Ok, you're not happy with the original "non-simple" domain fluff, but I see this as an aspect that has been refined over the years in the theory (if not in the implementation).
>> > However, an element in a tuple may happily be a set, a list, a RVA or
> > 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.
> >
> > whatever user defined type one wishes to use and still be 1NF,
>
> 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.
This is important. I don't believe anyone would see Codd's original paper (including probably Codd himself) as the final word - after all, it was over three decades ago and refinements are to be expected. It sounds to me your beef is over the "non-simple" domains aspect - but with user defined types, which many RM proponents promote, I honestly think there is no disagreement to be had here.
"Barney is_colour green and is_colour purple"
translates best to which of the following propositions:
>
> Cheers! --dawn
Received on Tue May 02 2006 - 04:52:03 CEST