Re: Multiplicity, Change and MV
Date: Sun, 16 Apr 2006 16:59:04 GMT
Message-ID: <sJu0g.60851$VV4.1129162_at_ursa-nb00s0.nbnet.nb.ca>
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...
>>>
>>>
>>>
>>>>Ok, I'm gonna take a stab at this from a 'classic MV' perspecitve, ala
>>>
>>>Pick.
>>>
>>>>(wanted to yesterday, but waited until some SQL responses percolated a
>>>
>>>bit)
>>>
>>>>So here goes...
>>>
>>>Do you understand the RM responses
>>>
>>>
>>>>First off, the schema is no problem at all and modifying it later also
>>>
>>>poses
>>>
>>>>no threat to data integrity, consider the following:
>>>
>>>>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 >>>>In the RM we have relations and relational/domain operators.
>>>>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 ?
>>>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 > ? > >
>>Note to BFaux -- After a few years of trying, I am still learning the
>>cdt language and still get taken to task for it. This is often not a
>>meet-you-half-way dialog, but hang in there. Your terminology is as
>>valid, just not what is taught in the schools which seems to focus on
>>very few aspects of any theory behind implementing good database
>>solutions.
> > > I did not mean to imply that. > I showed the RM perspective. > >>>>What are these "within" and "placed".
>>>>"Courses" would be a file/table with primary elements having id's
>>>>identifying them independently such as:
>>>
>>>>Courses = { (name:French101), (name:English105), (name:German203) }
>>>
>>>>Within each of these would be placed elements that relate to that
>>>
>>>particular
>>>
>>>>course, such as , prerequisites, class locations, lecturers, etc.
>>>
>>>In the RM it make no sense to talk about "within" and "placed".
> >
>>Were you really confused by these terms or just irritated that
>>potentially imprecise and certainly non-RM terms were used?
> > > I'm not irritated. Nor confused. :-) > I wonder if those who use them are confused by them or there are some > precise definitions of them. > I showed the RM perspective. > >>>>
>>>The relations are.
>>>
>>>
>>>>Another file/table for "Lecturers" with primary elements similar to
>>>
>>>courses,
>>>
>>>>but pertaining to lecturers such as:
>>>
>>>>Lecturers = {
>>>>(id:1, name:Tom, {teaches: {French, German}, play {tennis}} ),
>>>>(id:2, name:Bob, {teaches: English, play{violin}} )
>>>> }
>>>>
>>>>In "Pickdom" we don't usually concern ourselves with all of the
>>>
>>>sintactical
>>>>delimiter boardering ({}) et.al. so I'll model it in a more
> > conventional >>>>
>>>>Pick-like form:
>>>>
>>>>---
>>>>File "Courses"
>>>>
>>>>ID - French101
>>>>LECTURER - Tom
>>>>ROOM - Bldg A/Rm 106
>>>>PREQUESITE - (null)
>>>>
>>>>ID - German105
>>>>LECTURER - Bob
>>>>ROOM - Bldg B/Rm 200
>>>>PREREQUISITE - German101
>>>>
>>>>---
>>>>
>>>>File "Lecturer"
>>>>
>>>>ID - Tom
>>>>COURSE - French101
>>>>PLAY - Tennis
>>>>LIKES - Wine
>>>>
>>>>ID - Bob
>>>>COURSE - German105
>>>>PLAY - Violin
>>>>LIKES - (null)
>>>>
>>>>---
>>>>etc...
>>>>Now to extract the meaningful data we would construct a sentence such
> > as; >>>>>And then if we execute a sentence like; SELECT LECTURER IF COURSE =
>>>>SELECT LECTURER IF COURSE = "French101" - this will return a single
>>>
>>>result
>>>
>>>>of Lecturer "Tom"
>>>>
>>>>If it turns out that Tom also qualifies to teach German105, then
>>>
>>>"German105"
>>>
>>>>would be added to his record such as:
>>>
>>>>ID - Tom
>>>>COURSE - French101]German105
>>>>PLAY - Tennis
>>>>LIKES - Wine
>>>
>>>>"German105" - this will return a result containing BOTH Lecturer
> > "Tom" >>>>
>>>and
>>>>"Bob" because they both contain the value of "German105" in their
> > Courses >>>>
>>>>attribute in their data record (column).
>>>And your code would not require change because instead of the assumed
> > one >
>>>lecturer, it will get two of them now ...
>>
>>The point is that a "vocabulary item" such as the name of the attribute
>>LECTURER does not assume the cardinality. The property of the
>>attribute LECTURER that says whether it is single or multi-valued would
>>be changed (so metadata would change) but nothing in the existing code
>>would break by making that change. Nothing. How cool is that?
>>Forms/screens/UIs to update a list instead of a single value would need
>>changing, although software can be written in such a way as to minimize
>>this too (add or remove scroll bars).
> > Now I'm confused :-) > The change need more change, not in the code, but in the UI ?
Don't believe a word of these idiots. We established years ago that the meaning of existing queries changes very subtly depending on whether the 'COURSE' is an array of strings or of references to a COURSE file. However, Pick obscures this fundamentally important distinction from causual users.
Further, we also established that self-proclaimed experts in Pick were utterly and completely incapable to understand the subtle meaning changes leading me to conclude that even experienced Pick DBA's will happily jump into the trap.
The product is dangerous. Only an ignorant loonie would use it. Received on Sun Apr 16 2006 - 18:59:04 CEST