Re: MERGE as the imperative form of aggregation

"Marshall" <marshall.spight_at_gmail.com> wrote in message news:1176698788.879362.35910_at_y80g2000hsf.googlegroups.com...
> On Apr 15, 8:16 pm, "Brian Selzer" <b..._at_selzer-software.com> wrote:
>> "Marshall" <marshall.spi..._at_gmail.com> wrote in message
>>
>> > I find the symmetry and completeness of insert/delete to be
>> > compelling. My reaction is that update is *already* an "ugly
>> > combination of insert and delete."
>>
>> Update may be "ugly," but it's a necessary and primative operation. It
>> is
>> not just a combination of insert and delete. Because a key value can
>> only
>> be used to identify a tuple in single database state, update provides the
>> means to correlate the tuples in the preceding state with those in the
>> succeeding state so that transition constraints can be enforced.
>
> Well, I do not consider it a given by any means that transition
> constraints are necessary or primitive. In fact I'm not even
> sure if they aren't perhaps actually a bad idea. I'm open
> to discussion on the topic.
>

Codd thought they were important enough to include in his definition of a data model:

>>>

1 WHAT IS A DATA MODEL? It is a combination of three components:

1. a collection of data structure types (the building blocks of any database that conforms to the model);
2. a collection of operators or inferencing rules, which can be applied to any valid instances of the data types listed in (1), to retrieve or derive data from any parts of those structures in any combinations desired;
3. a collection of general integrity rules, which implicitly or explicitly define the set of consistent database states or changes of state or both -- these rules may sometimes be expressed as insert-update-delete rules. <<<--DATA MODELS in DATABASE MANAGEMENT, E. F. Codd, 1980

As for whether or not transition constraints a good idea, wouldn't you look silly wearing your boxers on the outside of your jeans? If you can model its content with a state machine, then you can define transition constraints to prevent garbage from getting into the database. Any mechanism that will keep garbage out is a good idea.

> In any event, if we accept the necessity of transition constraints,
> then it does seem as if we might have to accept the existence
> of update as a primitive. (Otherwise my earlier claim holds.)
>
>
>> > Triggers, sigh. I have a poor grasp of what they are for and
>> > what they mean from a theoretical standpoint. What are they
>> > necessary for? I have seen good descriptions of how to
>> > express view updating as triggers that model the inverse
>> > view, but would that be necessary if we had full view updating
>> > in the engine? What are triggers necessary for? I am clear
>> > on the value of *notification* of changes being sent to other
>> > components, but *actions* are less clear to me. Especially
>> > "instead of" actions.
>>
>> From a theoretical standpoint, triggers are necessary because there is no
>> deterministic mechanism defined in the Relational Model to correlate
>> tuples
>> during a transition from one database state to the next.
>
> Again, I do not accept as a given the desirability of correlating
> tuples. In fact it seems pretty clearly against the spirit of
> the relational model, at the very least.
>

How can you determine whether a change of state should be allowed if you can't reference the previous state?

Can you elaborate on why you think it's against the spirit of the relational model? The mechanism that you snipped simply exposes to the developer exactly what changes the user submitted so that set-based constraints can be declared that determine whether or not to reject that submission. When a user issues an update, THE CORRELATION IS SUPPLIED!!! It is only when that update is translated into an assignment that the correlation is lost. If discarding relevant information is in the spirit of the relational model, then that's news to me.

>> You can't use a key: [large snip]
>
> I definitely *don't* want to have the whole keys/correlating
> tuples conversation again!
>
> Instead, I would like to discuss the application or importance
> or theoretic foundation of transition constraints and/or triggers.
> Anyone?
>
>
> Marshall
>
Received on Mon Apr 16 2007 - 10:36:49 CEST