Re: Lucid statement of the MV vs RM position?
Date: 1 May 2006 16:20:57 -0700
Message-ID: <1146525657.263941.305480_at_v46g2000cwv.googlegroups.com>
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.
>> > within a certain type of context. That is hard to recreate in an
> > 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
> > 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. 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.
However, an element in a tuple may happily be a set, a list, a RVA or whatever user defined type one wishes to use and still be 1NF, 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.
> In theory (since I don't know
> in practice with SQL-DBMS's), there are some good times to model in
> NF2, I would think. For example, when a property of a strong entity is
> multivalued, it makes sense to model it as a relation or list-valued
> attribute. For example, for most implementations, a set or list of
> valid e-mail addresses for a person. Of course there are veritical
> industries where it makes more sense to retain e-mail addresses even
> when there is no person associated with the e-mail address.
>
> If we are going to (re-!)introduce nested structures, we should have a
> good idea when a logical data model should include them, or at least
> know some best practices. If a particular DBMS is not up to the task
> of working well with performance or ease of queries with the nested
> structures, then perhaps the actual implementation needs to normalize
> (1NF). But I'm not seeing nested structures yet in logical data models
> (not that I'm seeing all LDMs).
>> > could be, depending on your definition of "business problem", too
> > > > > [...] Unfortunately, there are no industry performance measures
> > > > > of which I am aware that are not designed strictly for SQL-DBMS's (or
> > > > > do you know of some?)
> > > >
> > > > Simply translate they SQL queries to queries in the ad-hoc query
> > > > language of your favorite system. Presuming, of course, that this
> > > > ad-hoc query language is powerful enough.
> > >
> > > You would need to implement solutions to the same business problems.
> >
> > Yes, if you are only interested in execution performance. But, again,
> > for a meaningful comparison between the two technolgies that approach
> > myopic.
>
> I would be interested in the use over time, with multiple apps.
>> > Not necessarily. Indirectly this sometimes also matters to the
> > > > Any extra required
> > > > programming would of course make the comparison meaningless.
> > >
> > > Not to an end-user, but, yes.
> >
> > end-user.
>
> I agree that if you have to hold everything and write new code, that
> would matter to end-users, but whether a system was written this way or
> that, end-users would typically not consider such comparisons
> _meaningless_, even if they also care about the underlying technology.
> Cheers! --dawn
Received on Tue May 02 2006 - 01:20:57 CEST