Re: MultiValue Databases

>> As indicated, one needs to use a different RM schema to support the
>> additional data/queries requested after the initial db/schema was
>> completed. Also, in some circumstances, one might need to either move
>> the original data to new db or update existing db rather then recreate
>> the entire db from scratch. Notice that xrdb did not require such
>> changes to accommodate additional data/query in this particular case.
>
> You have demonstrated no such thing. adding new data to any database
> requires moving it to a new state. That applies to your network DB
> as well as RM databases. So even your DB might have to be moved
> to other storage if the allocated storage ran out.

Please review prior post with consolidated xrdb and RM scripts. What it shows (admitted with a simple example, where I had to post the RM script myself since no one would engage and believing that an initial example should be simple) is proper (not chaotic) xrdb and RM methodology to model/store the initial data. Then it shows, in order to accommodate new data unknown at initial design time ("John like Mary" and the query to find relationship between John and phone#) that xrdb did not require the USER to update schema or move data to new db, while RM did. While xrdb may or may not have moved things in memory the USER did not. What xrdb (or any other methodology) moves in memory is, for all practical purposes, irrelavent to the user. Having to update the schema of a db with data or create a new db and transferring the original data is very relavent to the user. Why wasn't RM able to handle the new schema/data/query as effortlessly as xrdb did in this case? Would someone like to try a more elaborate case (ie computer systems or property listings)?

> You serve a useful purpose in this group by demonstrating what
> design choices and database models to avoid.

Could you complete the missing query to find persons with phone# 111-1111 and 222-2222 using the new RM schema? The comparable scripts may help demonstrate which design choices and database models to avoid, in similar simple cases.

> Day after day you make the same wrong headed arguements.

Could you assert the main one and proceed to demonstrate it with an appropriate verifiable example? Per Lee, "hand waving, cliches and emotional appeals are simply not sufficient". Received on Thu Jun 09 2005 - 19:30:33 CEST