Re: The Practical Benefits of the Relational Model

paul_geoffrey_brown_at_yahoo.com (Paul G. Brown) wrote in message news:<57da7b56.0210281709.262a4094_at_posting.google.com>...
> Call it what you will, but the concept of a 'user-specified unit of
> work' seems to me to be a necessary feature of any data language. At points
> within a multi-query operation the database can be inconsistent, but not
> at the end.

Isn't this just a question of syntax?

Suppose our query language could only insert one value into one column and one row at a time. Then to insert a whole row we would need one statement for each column, all contained in a transaction. But instead we have a relational operator with this transaction "built-in".

Then suppose we have a table with the constraint that a specified column must always sum to a constant. To change the value of the column for two rows (say to add a certain amount to one and subtract the corresponding amount from the other) would take two single-row updates in a transaction. But then we just have a relational operator that can do multi-row updates, thus shifting the transaction "inside" the query language.

Suppose now we have two tables that have some cross-table constraint that is only satisfied when we add a row to each in the same transaction (with deferred constraints?). (e.g. each table has a foreign key reference to the other). Could we not define some "multi-table insert" statement that did this in one implicit transaction?

So in this way we just extend the query language so the transactions all become implicit rather than explicit. I'm not sure if there is a finite set of these extra statements that will cover all possible cases - maybe not.

So maybe there is no fundamental right or wrong answer to this - just a case of what "level" we want the transactions at.

Actually thinking about it some more, maybe there are two distinct cases here:
1) transactions to adhere to database constraints (the database will not allow row r to be inserted unless row s is as well). 2) transactions to adhere to ad-hoc "constraints" (the user doesn't want to insert row r without also inserting row s, even though the database would allow it).

Paul. Received on Tue Oct 29 2002 - 11:16:04 CET