Cart
[Home] [By Thread] [By Date] [Recent Entries]
# # These are all examples of the software applying too rigid a test # and failing with real-world data. # Every example of an integrity constraint that I have ever seen in a database textbook has been flawed, in the sense that it fails the test "are there any conceivable circumstances in which this constraint could prevent me representing the state of the real world accurately". In practice, such integrity constraints (and the same goes for XML Schemas) are there for two purposes: (a) to detect data that is more likely to be wrong than right, and (b) to protect the receiving software from having to deal with situations that it hasn't been designed to cope with. If you think you are describing situations that can't happen in the real world, you are probably deluding yourself. (An example. A retail system in France kept rejecting a particular transaction. It was programmed to reject the sale of an item that would make the stock level negative: i.e. the supermarket couldn't sell more of an item than it had bought. On investigation, it turned out that the product in question was live fish, and they were breeding in the tank). Michael Kay
|
