Re: Multiplicity, Change and MV

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1145292548.823950.44180_at_u72g2000cwu.googlegroups.com...
>
> x wrote:
> > "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> > news:1144858576.001309.90750_at_z34g2000cwc.googlegroups.com...
> > >
> > > x wrote:
> > > > "B Faux" <nospam_at_nospam.net> wrote in message
> > > > news:EvS_f.24004$NS6.8332_at_newssvr30.news.prodigy.com...
> > > >

> > > > > The general concept relys upon the granularity of the data
> > requirement,
> > > > that
> > > > > is to say, how much detail do you want to store about each
element?
> > In my
> > > > > experience we should allow for as much detail as possible, so I
would
> > > > > recommend building a seperate MV file (SQL table?) for each
primary
> > > > element.
> > > >
> > > > What is an element ?
> > > > In the RM we have relations and relational/domain operators.
> > > > It make no sense talking about "stored detail about each element".
> >
> > > Given that "MV" is in the subject and that is the generic term for
> > > MultiValue, aka Pick, solutions, I would think we could let him speak
> > > his language. The fact that the RM doesn't care about words like
> > > "detail" does not mean that database theory should be without such
> > > words.
> >
> > I did not mean to imply that.
> > I asked what is an element. An element of what ? Weather ? Chemicals ?
Atoms
> > ?
>
> OK, sorry I jumped on your response, x, but my guess was that you
> understood the term and were nitpicking. I'll figure I was wrong on
> that. I suspect the loosely used term "primary element" would be said
> more precisely as a "strong entity" where "element" (used below too, I
> see) could be "entity."

I've just found the element : http://www.log24.com/notes/DiamondTheory.html Received on Tue Apr 18 2006 - 12:17:18 CEST