Re: The Practical Benefits of the Relational Model

"Peter Koch Larsen" <pkl_at_mailme.dk> wrote in message news:3daff6fa$0$34808$edfadb0f_at_dspool01.news.tele.dk...
>> Now these users *cannot be trusted*. We must allow them to be stupid
>> and/or malicious and still maintain a working and integral database.
>
> I believe the very fact that they are given access to (part of) the data
> implies that they are to be trusted to some degree.

People are people. If they have the *right* to some data, they can't (generally) be forced to be *responsable* in their access and update of such data.
If we want to allow users to access their data in anyway and with any tool they see fit, our RDBMS has to be robust in the face of badly coded and malicious applications and users.

> > If users need to wait for other stupid/malicious uses to complete
> in-flight
> > transactions, then the database will not be useable. E.g.
> >
> > BEGIN TRANSACTION
> > UPDATE table SET col = X
> > <go on holiday for two weeks>
> > IF RAND() > .5 COMMIT
> > ELSE ROLLBACK
>
> But this would be possible even with the D4- language - or? My impression
is
> that if GoOnHolidayForTwoWeeks is a operator, the effect of
> table := table + < tuple>,GoOnHolidayForTwoWeeks() would have about the
same
> effect.

Good point. However the GoOnHolidayForTwoWeeks() would be implemented outside of the users environment by someone who we could trust, and therefore either it would return a value in a reasonable time, or our trusted user (call them a DBA say) would not create such a function.

Similarly, including a function such as Wait() as a user visible function in a RDBMS would not be very sensible.

> > Traditionialy such problems are fixed by mandating database access only
> via
> > trusted 'applications', but going forward we should be looking at
complete
> > application independence for the RDBMS, which means that you cannot
> *trust*
> > the applications accessing your database.
>
> Is that so? I must admit that i am not sufficiently familiar with
> traditional RDBMS applications, but my immediate guess would be that some
> time-out mechanism would be solved instead.

Yearh you would have thought that. Time outs on waiting for other transactions yes, but not time-out on the length of a given transaction. Even if you have such timeouts, to stop malicious users you would need to stop them immediately (and continuously) re-issuing long running transactions.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Fri Oct 18 2002 - 19:14:36 CEST