Re: Demo: Modelling Cost of Travel Paths Between Towns

Neo wrote:

>>I thought YOU were the Original poster, at least that's how it looks

>>>CREATE2 (a.goto=b).weekday = +monday;
>>>The + indicates that if monday does not already exist as an instance
>>>of the verb (weekday), go ahead and create it.
>>
>>How does the language distinquish between the operation or changing the 
>>value to +1 from the operation of adding a new instance with the value 1.

I asked about NUMERIC operations. Sounds like your DB cannot do arithmetic like SQL:

update people set age=age+1 where name='john' ;

Too bad.
>
>

>>Matching that model in a Relational data model is easy enough.
>>(Joe Celko already posted a SQL model.)

Code changes can be minimal when using views. But it is annoying that you pose a toy example and then complain that the RM schema is a toy schema. The changes you suggest here would not be hard to add, even if we let the table become denormalized.

>
> In fact, in the original XDb2 solution, two towns could possibly have
> the same name. To distinguish them would require specifying which
> towns it goes to. For example suppose we change town c's name to
> string 'a' (via GUI). One can still find the original town a (top-left
> position) because only it goes to town b and what used to be town c
> (now named 'a') using the following query:
>
> SELECT2 %.cls=town & %.goto=b & %.goto=(%.cls=town & %.name='a');
>
> In RM's current solution, symbol and town name are the same thing
> resulting in inflexiblity in above case. In XDb2's solutions a symbol
> or string names a town which is a different thing than the symbol or
> string. RM has its own advantages which I did not list here.

Now your model seems at least as muddled as the RM solution. You cannot distinquish between the two towns named "a" with out strange contortions.

Now you are going to come back and say, something along the lines that c.name is different from a.name though they have the same values.

  Well then I would say Joe DID leave out an ID column in his model, and I would populate that with your object ID. In some databases, I wouldn't even have to do that, as it it possible to get a pseudo-column row ID value.

And yes I know many of RM advantages, I am losing any confidence of seeing advantages to your DB. The syntax is awkward, the model is hierarchical (ie, ancient), and your presentation is no well thought out. There may be advantages to your approach in some applications, but I haven't seen them so far. I'll try to keep an open mind, but you are losing me quickly.

-- 
Ed Prochak
running    http://www.faqs.org/faqs/running-faq/
netiquette http://www.psg.com/emily.html
--
"Two roads diverged in a wood and I
I took the one less travelled by
and that has made all the difference."
robert frost