integrity constraint
-
For example to transfer the sum of $100 from account 123 to account 456. we want the total number of dollars in accounts 123 and 456 taken together not to change.
Why it would be unreasonable to declare an integrity constraint to that effect?That is what transactions are for, wrap the transfer in a transaction if there is an error roll back the transaction. An after process integrity check is not unreasonable but the correct way is with a transaction.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
That is what transactions are for, wrap the transfer in a transaction if there is an error roll back the transaction. An after process integrity check is not unreasonable but the correct way is with a transaction.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
The book should say it is incorrect or redundant and should recommend using a transaction. All books are not 100% correct all the time.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
For example to transfer the sum of $100 from account 123 to account 456. we want the total number of dollars in accounts 123 and 456 taken together not to change.
Why it would be unreasonable to declare an integrity constraint to that effect?Tara11 wrote:
Why it would be unreasonable to declare an integrity constraint to that effect?
Mainly because integrity constraint operate on row-basis. Transactions then again ensure that the operation is completed as a whole even when multiple commands are affected. But neither of these guarantee that the total sum is unaffected when money is transferred. If this would be a single table operation, a trigger could be utilized to do that check.