Re: Jan's well-defined view updates definition

Mikito Harakiri wrote:

> "Jan Hidders" <jan.hidders_at_pandora.be> wrote in message
> news:d14ab.25480$rw3.1352807_at_phobos.telenet-ops.be...

>> Mikito Harakiri wrote:
>> >
>> > We can't continue going round and round, so let's move on to the second
>> > paragraph of your definition.
>>
>> Well, I would still be interested in your opinion on whether the
>> definition
>> I gave makes sense or not, and what the intuition is behind the
>> definitions
>> you gave. It's almost as if you are affraid of such discussions.

If you don't show that they correspond to something meaningful they remain sterile and only interesting in a mathematical way. That may be all that you are interested in but I want more.

> It is not if your definition makes sence or not, because given a set of
> equations that has multiple roots we can be very inventive defining the
> "best" or "most natural" solution.

I don't think we can. Only a few of them make sense, and I would even argue that only one of them really makes sense.

> As far as the best intentions to serve the user are concerned, that
> doesn't always work either. Semantic web, XML and other buzzword
> innovators claim solving very practical issues. But their theory is poor.

Who else should we serve? Ourselves? The only lesson that is to be learned from your examples is that what might look like serving the user on the short term might actually be a disservice on the long term. But the goal is always to serve the user. And to protect, of course, against themselves. ;-)  

>> > "Jan Hidders" <jan.hidders_at_pandora.be> wrote:
>> >> Finally, we define a view V as *updatable* by a certain set of updates
>> >> U
>> >> if
>> >> for all databases D that satisfy the schema all updates in U are
>> >> well-defined. Additionally we say that V is *commutatively updatable*
>> >> by
>> >> U if for all databases D that satisfy the schema it holds that if two
>> >> series of updates from U have the same result when applied to Q(V) and
>> >> perform only well-defined updates then they result in the same
>> >> database when applied to D.
>> >
>> > Could you please provide a non-commutatively updatable example that we
>> > can
>> > discuss?
>>
>> Lets say I have base relations R(a,b) and S(b,c) with a foreign key R.b
>> -> S.b and a view V that is defined by the natural join of R and S. The
>> additions and deletions are both well-defined but if I add the tuple
>> (a1,b1,c1) and then remove it then the end result is an additional tuple
>> (b1,c1) in S, which is not the same as the end result of adding 0 tuples.
>> So for the class of updates that consists of inserts and deletes it is
>> not commutatively updatable.

Sure, but so what? What is so special about this property that makes you want to restrict severely which views users can update? I certainly can see some benefits (otherwise I would not have proposed the definition) but you seem not even willing to contemplate the possibility of losing it.

• Jan Hidders