Re: Requirements for update languages?

Jens Lechtenboerger wrote:
>Hi Jan, sorry for being late but your article did not appear on our
>university news server...

That's ok. We sometimes have the same problem here.

>hidders_at_REMOVE.THIS.uia.ua.ac.be (Jan Hidders) wrote in message
>news:<3dcde82e$1_at_news.uia.ac.be>...
>
>> Ok. So let's look at this more closely. Let's say we have tables EMP(Emp#,
>> Dept#) and DEPT(Dept#) with a foreign key from EMP.Dept# to DEPT.Dept#. If I
>> now only have DEPT in my view then if I delete a department I also delete
>> all its employees. However, if I then again add the department (because I
>> made a mistake the first time) then the employees are still gone. You would
>> probably claim that this is not a good view because the user can delete
>> employees but not put them back. I would argue that it is not the user who
>> has deleted the employee, but the database. Compare this to the situation
>> where there is no foreign key, but another user who has gotten the task of
>> firing all employees that do not belong to an existing department. Also then
>> it could happen that you delete a department and after a while you put it
>> back and then you are left with a department without employees. I don't
>> think there is really such a big difference between the database computing
>> some extra updates after you have committed and another user that bases some
>> of his or her updates on the data you committed.
>
>I see a difference. If *the database* does additional updates, then
>those updates are executed within *my* transaction and *I* feel
>responsible for my transactions. I don't feel respnsible for
>transactions of other users.

Perhaps your sense of responsibility is just too big. :-) But seriously, I find these good arguments. However, I tend to be a bit agnostic on the question whether restricting views as you suggest is *always* a good idea. The way I see it is that it probably depends on how much trust we have in the "steadiness" of the user, i.e., do we believe that the user will often revert his or her updates or not. If the user is unsteady then we will want to limit the damage that is caused by this. That other transactions will act upon the false data is inevitable. But what can be helped is the propagation of updates through constraints. (I regard views here as equivalent to base tables that happen to be defined completely by certain constraints.) If you don't trust the user enough then these constraints probably shouldn't be there.

So my advice would be to make your claim a bit weaker and say only that for certain groups of users it is important to check the constant-complement property.

• Jan Hidders