Re: Demo: Modelling Cost of Travel Paths Between Towns

From: Alan <alan_at_erols.com>
Date: Fri, 19 Nov 2004 15:47:54 -0500
Message-ID: <3074fpF2tfiu1U1_at_uni-berlin.de>


"Neo" <neo55592_at_hotmail.com> wrote in message news:4b45d3ad.0411191145.2b92d71b_at_posting.google.com...
> > > "SELECT %.age & %.name=john" works until eternity.
> > > Could you show RM's query that will work until eternity.
> >
> > CREATE TABLE test (class VARCHAR2() PK, name VARCHAR2() PK, age NUMBER);
> > INSERT INTO test VALUES (put the values here);
> > SELECT * FROM test WHERE age > 0;
> > ALTER TABLE age ADD color VARCHAR2(50);
> > UPDATE age SET color = 'brown' WHERE class = 'Tree Trunk';
> > SELECT * FROM test WHERE age > 0;
>
> Could you fix the above, I want RM's query to find anything named john
> and has an age, without NULLs or redundant representations. Assume
> RMDM and R2D2 are two robots sent to Mars. They are similar except for
> their database. RMDM is based on RM and uses your above initial
> schema. R2D2 is based on XDb2 which doesn't require a "schemas" per
> se.
>
> Landing on Mars, RMDM and R2D2 meet a martian who doesn't have a name
> and his age is unknown. Here is how R2D2 represents him using XDb2:
>
> // Create a thing named martian
> CREATE *martian.cls = thing;
>
> // Create a thing whose class is martian
> CREATE *;
> CREATE it.cls = martian;
>
> // Execute query
> // Finds nothing
> SELECT %.age & %.name=john"
>
> Please show how RMDM deals with the above (without NULLs and
> redundancy) starting with your corrected initial schema. If you
> weren't expecting this case, surprise #1.

No surprise. Happens all the time. That's why the RM separates data from programs.

It would be redundant of me to explain this trivial process to you yet again, as the procedure is exactly the same as it has been in the past, but for the LAST time:

Since I don't know his name, I have no way of uniquely identifying him from any other Martian whose name I do not know. You don't either. I would need to create an artificial value to assign to his name, so I'll call him Neosense1. Maybe one day, he will use his real name, and I can issue a simple UPDATE statement. I don't know what you will do. I also need to add a column to handle the new attribute you just found out about (database type)

ALTER TABLE test
ADD db_type VARCHAR2(100)
;

INSERT INTO test VALUES(whatever they are, but name='Neotest1', age='-1') ;

To update the db_type values, I would... UPDATE test SET db_type = 'RM'
WHERE name = 'RMDM'
;
UPDATE test SET db_type = 'XDb2'
WHERE name = 'R2D2'
; Received on Fri Nov 19 2004 - 21:47:54 CET

Original text of this message