Re: Lucid statement of the MV vs RM position?

David Cressey wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
>
> > Because the "schema" is descriptive rather than prescriptive, it
> > depends on your dictionary, how you define the attribute, as to whether
>
> I don't understand the distinction between descriptive and prescriptive.

It doesn't matter how you describe the data in any data dictionary (schema), your CRUD services (the C and U, specially) can put any data into the database. The metadata does not constrain the values.

There is weak typing (close to no typing). Everything is a string unless a binary value. Attributes are identified by position (LOC). You can then describe the value at that position in whatever ways are useful. These descriptions have to do with how to use or query attribute values. You can define as many vocabulary terms for your dictionary as you want for any particular attribute.

So, you could describe (define) an attribute as MultiValue and Pick will treat it like a list. Then you could define that same attribute as single valued (not done frequently), in which case you would get the string with the value marks in it and you could hand-parse it.

You could describe LOC 5 as CUST_ID to be a single-valued string and CUST_NUM to be a number and have these describe the same attribute. It then becomes a form of duck typing. As long as a value can act like a number, for example, if you treat it like a number it will play along.

Additionally, you can define LOC 4 as CAR_COLOR and then later decide that due to new requirements and new FD's you are going to split out CAR_COLOR into another file. Then you add CAR_ID at LOC 23, stop using LOC 4 and redefine CAR_COLOR as a virtual field (no LOC) in this file so that it "gets" the color from the new file. The queries all still work because in some sense when it comes to querying, because the dictionaries are all merely descriptive, they are all like views in that they are "logical files" where you can redefine LOCs and attribute names however you need to.

Like SQL, Pick has miles to go, but there really are concepts worth moving into the future in a more industry-standard way (NF2, 2VL, nested lists, variable length everything, duck typing...). There is a rather big chasm between duck typing and strong typing, however, and I haven't figured that one out. Cheers! --dawn Received on Tue Apr 25 2006 - 03:10:52 CEST