Re: Demo: Modelling Cost of Travel Paths Between Towns

"Neo" <neo55592_at_hotmail.com> wrote in message news:4b45d3ad.0411162100.58dedf09_at_posting.google.com...
> Neo: user can easily create code that will update the age of any thing
> whose name is john and has an age, including that of things whose
> class is unknown at design-time (ie a person, dog, cat, pig,
> plane, gizmo, widget, etc in the future). Try coding that in RM.
>
> Alan: I really think you have no clue at all.
>
> Neo: So let's step thru it and fill in the details:
>
> 08:45 - Alan creates table "your_table"
> Please show your db's schema
> and in particular your_table's fields here.
> Note: At this time you do not know
> what type of things Neo will added at 11.

I will, because that is part of gathering requirements. If you can't tell me what you data you will want to see two hours from now, you will not be working here much longer.

> 09:00 - Alan writes following query:
> UPDATE your_table SET age = age + 1
> WHERE name = 'john' AND age IS NOT NULL;
> Note: A query that finds all things with age
> and name john is sufficient to illustrate point.
> The query should not mention NULL anywhere. Why?
> Because you db shouldn't have NULLs to begin with.

I did that already: WHERE age > 0, etc, though I personally have no problem with NULLs, nor have they ever given me a data problem. If you know they're there, and know what they represent, it's acceptable. Not perfect, but workable. It's easy enough to avlid them, anyway, if one really wants to, as in my age = 0 or age = -1 example (some societies (I beleive the French, E.g.) may consider 0 a real age, hence the -1 option)

> Don't forget to anticipate things without names
> or multiple names.

If the name is the PK, which has been assumed (by me and everyone else except _maybe_ you) for this simple example, there will always be a name, or it the row won't be in the database. Anyway, why would I store something about which I know nothing? Your example makes no sense.

 In fact, don't forget to
> anticipate the unanticipatable.

Hold on, let me get out my crystal ball. But seriously, relational design does anticipate the unanticipatable to the degree it can be anticipated. That is what 1:M and M:N relationships are all about. It is impossible to anticipate data elements that don't exist yet. If they do exist, they can be anticipated and included (or not if that is one's choice).

> 10:00 - Neo will adds some thing.
> I will tell you AFTER you have finished you db's schema.
> You can bet I will add something your db schema
> didn't anticipate at 8:45.

That's when I use the ALTER TABLE statement (and shake my head).

> If necessary, we will modify your db's schema
> to represent the new things w/o NULLs or redundancy
> (I'll let redundant symbols slide).
> 11:00 - I run your query that you created at 9:00.
> I assert your query will most likely fail
> (unless you use generic modelling, similar to what
> Hugo had implemented for Common Ancestor Report,
> only moooooore generic)

I modified the table at 10:00 after you told me what you forgot you needed, so now it is included.

>
> Under above type of conditions, XDb2's (SELECT %.age & %.name=john;)
> will be valid not matter what is added or how the "schema" is modified
> in the future.

But that is the beauty of the RDBMS and SQL. It's called program-data independence. A schema can be added to without changing any already-written

queries (if they are written properly, i.e. without using the *). Some other
kinds of changes can possibly be made, too, depending on many things. Is it
perfect? No, but it is not impossible, as you keep insisting.