Re: Demo: Modelling Cost of Travel Paths Between Towns

"Neo" <neo55592_at_hotmail.com> wrote in message news:4b45d3ad.0411112047.56e519d7_at_posting.google.com...
> > I thought YOU were the Original poster, at least that's how it looks
>
> The OP was in OT titled "Representing a Graph in an RDB...again...(BUT
> DIFFER...". For some reason, I failed to post there.
>
> > > 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.
>
> By enclosing it in quotes (ie CREATE2 (a.goto=b).weekday =
> +'+monday';). The portion after the optional + is the string that will
> name the new instance. The prior command creates a weekday named by
> the string '+monday' if it does not already exist. Currently UPDATE
> has not been implemented but it may look like this UPDATE2 john.age=35
> to 54; or UPDATE2 john.favorite-word="to" to "too";
>
> > Matching that model in a Relational data model is easy enough.
> > (Joe Celko already posted a SQL model.)
>
> This problem didn't not have highly variable data and relationships or
> require a higher degree of normalization. This problem falls within
> RM's scope. Try adding a different property to each city or name two
> cites the same. RM solution will require some changes to schema and
> code already written against. XDb2 solution will be minimally
> affected. Script below shows how:
>
> // Add state property to existing town a
> CREATE2 *state.cls = thing;
> CREATE2 a.state = +texas;
>
> // Add population to existing town b
> CREATE2 *population.cls = thing;
> CREATE2 b.population = +10000;
>
> // Add a new town a, but in different state
> CREATE2 *a.cls = town;
> CREATE2 a.state = +florida;
>
>
> 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.

What you are not realizing is that "town" would never be a Primary Key, so it is easy in the RM to have more than one town with the same name. No big deal. Received on Fri Nov 12 2004 - 14:56:21 CET