Re: foundations of relational theory?

Good story, and a very common type of scenario, Albert.

If you think in terms of a paper system where "forms" are filed into "folders" you will find that with MV/PICK, as with a paper-based system, when you make a change to a "form" you don't have a lot of work with your filing system - you just change the form and keep moving. Additional fields, changes to the meaning or type of a field, and changes to the cardinality of a field on a form can often be made handily.

Similarly for retrieval -- just as the person doing the manual, paper filing would not tear up the form into bits only to have to reconstruct it again when asking for the form back, at the logical level, a form (or one might say "a proposition") is filed together in PICK, without a lot of tearing it apart. That makes it both easier and faster to get it back.

While this is not an academic statement of why PICK works nicely, it might give some hints on why folks who have put their dollars into the SQL-based RDBMS world can become born-again when they see the difference in dollars needed for a comparable PICK system.

Again, it is not that PICK is flawless (by any stretch), but as a basis for moving forward, I'd sure rather start with this big bang for the buck implementation than any SQL-based RDBMS I've seen. And, yes, I know this is a theory forum and not necessarily for opinions based on practice, so I'll go back to the claim, even though not fleshed out, that persisting data based on language -- such as modeling entire propositions together rather than piecing them apart to the extent done in an RDBMS -- makes sense because we are not trying to persist mathematical relations ultimately -- we are trying to persist propositions.

For example, "Jane Doe has three kids -- John, George, & Paul -- and also three cars -- a 1967 Mustang Fastback and a 1968 VW Bug, but the car she usually drives is her other car -- a 2002 Ford Thunderbird". A lousy sentence, but easy to image on a form. This sentence/form is about a single person -- Jane Doe and would all be filed in a single "folder" in PICK except, possibly, for code files used for validation -- there could be a code file for makes & models of cars.

Depending on the application, it might make sense to have 4 "forms" in this folder -- one for each person: Jane and each of her kids or we might decide it isn't important to treat the kids as separate "filed" persons in our system at this point. If they are filed as separate people, then the Jane Doe record (form/document/proposition) would have a multivalued foreign key (pointer) to each of the child (literally!) records, else it would store the actual data, such as first names of each child.

Playing the game with language to parse it out, split it into many fragments (often based on the nouns) for the purpose of storing it, only to need to retrieve it again as a whole, doesn't gain us anything, on the face of it.

[I understand the purpose is to be able to provide a simple language that enforces various data constraints, but I think that purpose is somewhat flawed too. Protecting data is a noble goal -- controlling data and programmers with fixed, global constraints isn't necessarily the best way to lend such protection in my opinion, but that's a tangent to this post, so later on that.]

--dawn

"Albert D. Kallal" <NOOSSPAMkallal_at_msn.com> wrote in message news:<z87jb.101186$9l5.78520_at_pd7tw2no>...

> "Bob Badour" <bbadour_at_golden.net> wrote in message news:oMGdnX_xJpsFqhGiU-

> 
> Potentially is the key here. Many times the allowing of a multiple value
> causes little, or no effects.
> 
> I recall in the early 90's when I was staying a campground (that was using
> MY MV database reservation system). The rule for this campground was one
> vehicle per site, and any additional people booked into the site had to
> leave their car in a overflow lot down the way (outside of the campground).
> It turned out that sometimes people needed to change vehicles, and allow a
> different vehicle into the campground (they would move the pass from one car
> to the other). Of course, the campground asked me if it was possible to
> modify the system to allow more then one vehicle (licence# etc) to entered
> into the system. I said sure, and proceeded to simply allow the licence
> field to be multi-valued. Instantly, the screen editor now would let users
> enter more then one value for the licence# field.
> 
> The result was that now more then one vehicle could be allowed into a
> campsite. Further, this change was DONE LIVE while bookings were being made,
> and cars were lined up outside of the front gate. The system did NOT have to
> halted, and bookings continued as normal. Further, all repost, and even
> search prompts (that asked for what license#) etc ALL continued to function
> correctly. This is simply one example of a live modification made to a
> system in use, and no code, forms, reports and queries needed to be changed.
> I have never used any sql based system that would allow such changes with
> ease, and further even less of those systems would allow this change WHILE
> IN USE. For the MV database, this change was a non event, but changed the
> functionality of the system to the end user. Total time for the change was
> less then 5 minutes, and with no down time.
> 
> For sure, not all changes are so slick and easy...but some certainly are. In
> a sql based system, both the forms, code, reports and even quires that
> search for a license# would all have to be changed. Quite a bit of work, and
> certainly not the kind of change one would make to system with cars lined up
> at the front gate.