Re: a union is always a join!

On Mar 7, 9:05 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> Clearly the series of
> events that describes the changing world contains more information than the
> series of snapshots, and as a result, database update mechanisms based on it
> promise both greater economy and precision since only what is different need
> be stated and since exactly which set of differences that results in a
> successor snapshot is clearly stated in each transition.  In addition, more
> granular transition constraints can be specified without resorting to the
> introduction of superfluous temporal attributes or identity fields.  What
> has time to do with the requirement that a traffic light that is green can
> only either remain green or become yellow?

A simple Traffic Lights database design

table TrafficLights (

   streetCrossId integer,

   state                 {red,yellow,green}

has no concept of light switching ordering. However, as soon as we have time added it becomes temporal database, and everything becomes more complicated, including queries! Yet, the constraint is expressible (although as quite unwieldy SQL assertion).

> I think that what is missing from commercial DBMSs is the ability to
> declaratively specify constraints that limit the behavior of objects, and as
> a consequence, those constraints and their enforcement have migrated into
> application code.  

Perhaps there are other reasons why constraint enforcement migrated into application code? Such as application programmers' ignorance of database fundamentals, client-server latency, and, most important, weak support from RDBMS vendors?

> My goal is to describe a logical framework under which
> all constraints can be specified declaratively--including transition
> constraints.  

Transition constraints are more complicated than state constraints. Think of simple inequality x < 10. How many transition constraints would it take to represent it? Assuming domain of integers we would allow transitions 1->2, 1->3, 1->4, 2->3, ... and reject 1->11, 3-
>12, ... How would you express functional dependency as a transition
constraint, without explicitly enumerating all legitimate state transitions?

I'd suggest that state constraints are much more common than transition constraints, therefore having transition constraints as a foundation seems to be a wrong idea. It requires quite a lot of effort and sophistication to develop something workable along this ideas -- we are looking into fields that study dynamics, in general, and differential equations, in particular.

Your criticism of algebraic foundation for constraint system might get some ground if you focus on (un)expressiveness and (im)maturity of underlying algebraic system... Received on Sun Mar 08 2009 - 19:28:15 CET