Re: Lots of code. How many tables.

First thanks for the pointers, this wil take some time to look into that.

> > There is a type X which has to be of subtype C or D.
> And Y is also a subtype of A.

Here my description failed because I see here a misunderstanding. (X and Y should not have been described as subtypes of the set, but as having relations with only those subtypes. My fault, sorry). But it would be wiser for me to read up on the subject first.

> That's a rather simple constraint of the form:
> ( books_loaned <= lending_limit )

There is only a list of books loaned in the 'logical' model, not a number of books loaned.
(The 'books_loaned' is not in the 'logical' model, because it is redundant, you can count the number of books loaned directly from the list of books a lender has.)

Offcourse this 'books_loaned' can be implemented. My point is you probably would use coding to get this 'field' filled with the actual number. (Trigger or application coding). I am not against introducing such a field and the coding to support this. Using code to get this 'books_loaned' filled with the actual number, is what I tried to explain as using code for implementing constraints. (Which was my point).

Maybe this is where the misunderstanding comes from. Any coding written to implement business rules which limit the actual variation of contents that the database can hold, is called a constraint by me. This can be anything, from complex tax-rules, limits on totals, agreements of sums, interaction of medication.
(For example for a financial institution the total amount of money going in should tally with the total amount going out. And although on a transaction basis this is often done during the transaction, there often is an 'overall' application program doing the total balance check.)

If all the constraints would be controlled by the database, there would be no reason to provide the high isolation levels like 'repetable read' and 'serializable'.

ben brugman Received on Mon Feb 16 2004 - 17:00:49 CET