Re: MultiValue Databases
Date: 9 Jun 2005 13:42:15 -0700
Message-ID: <1118349735.024329.215200_at_z14g2000cwz.googlegroups.com>
Neo wrote:
ed wrote:
> > 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.
the statements in xdb:
CREATE verb inst *like)
(CREATE john like mary)
are analogous to
create table verb (thisone char, relatedby char, thatone char)
// add PK and FK as desired
insert into like values ('john', 'likes', 'mary');
so the CREATE verb operator in XDB is analogous to the CREATE TABLE operator in a relational DB. So where is your advantage? I'll tell you, there isn't one. Try to learn something will you?
(SELECT john * mary) // Query returns like.
select relatedby from verb where thisone ='john' and thatone='mary' ;
Again, not too complicated.
You have never defined your * operator. What are it's limits? What would it return if the like did not exist, but they both shared a phone number? or some other indirect relationship? Please don't answer with an example. Tell me the rules the XDB engine applies.
Well given that 111-1111 is a PHONE number, the reference to JOHN is irrelevant (dare I say redundant?) We are not looking for arbitrary strings so this query is just plain silly. (I always say, there are no stupid questions. But the question this query represents comes close.) (SELECT john * 111-1111) // Query returns phone In english your query might be phrased "How is John related to phone number 111-1111?" Written out, it certainly seems silly. Don't you agree?
> 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.
And I showed that moving to a new DB was not necessary.
> Why wasn't RM able to
> handle the new schema/data/query as effortlessly as xrdb did in this
> case?
Because john chose to change to model. He wasn't forced to by the rules and properties of RM.
>
> > 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".
I just did.
Your claim: RM requires users to create a new db and transfer the original data to it for any change.
result of the above example: RM does not REQUIRE restructuring of the schema to accomodate new requirements.
the above is based on the premise that:
For any addition made in XDB, a logicaly equivalent change can be made
in the RM database without destroying previously stored data.
This premise was demonstrated by example. If you disagree that the
demonstration is valid then I'll prove it mathematically with one input
from you.
If your could present a mathematical model of your theory of data, I'll show that for any operation you can perform in your model, there is an equivalent operation in the relational model. The relational model is based in set algebra. What is your model based on?
After you give a mathematical model, then I'll consider that maybe you are not just waving your hands.
Until then, I'll just wave good bye. 8^)
Ed Received on Thu Jun 09 2005 - 22:42:15 CEST