Re: a union is always a join!

From: Tegiri Nenashi <TegiriNenashi_at_gmail.com>
Date: Mon, 9 Mar 2009 08:33:35 -0700 (PDT)
Message-ID: <28078b81-9b60-412d-915c-cbac79fcaf4b_at_l16g2000yqo.googlegroups.com>


On Mar 8, 3:45 pm, "Brian Selzer" <br..._at_selzer-software.com> > During a database update, assuming that streetCrossIds are permanent
> identifiers, the relations,
>
> TrafficLights- {streetCrossId, state},
> TrafficLights% {streetCrossId, state, streetCrossId', state'}, and
> TrafficLights+ {streetCrossId, state}
>
> would be populated with tuples representing those traffic lights that have
> been removed from service, those traffic lights whose state is now
> different, and those traffic lights that have been placed into service
> respectively.

This is not a good example of database update. Why do we care what state traffic light was during maintenance upgrade? I suspect they turn it out before actually unplugging the electrics and removing other mechanical artifacts. Moreover, the state is probably a calculated value, function of time and perhaps some other conditions.

Any other realistic example of transition constraint?

> I think you've misinterpreted my intent.  I did not intend that state
> constraints be rewritten as transition constraints.  I intend instead that
> both state constraints and transition constraints can be specified
> declaratively.

Good luck with that. For transition constraints you'd have to summon automata theory? That is not one of the prettiest subjects of computer science... Received on Mon Mar 09 2009 - 16:33:35 CET

Original text of this message