RE: Philosopical debate about constraints

Even under these narrowly defined conditions I still like constraints. I am making the assumption that this is a OLTP system. Reasons: 1. Finding bugs in software is easier. 2. Blaming anomalies in program behavior on bad data becomes impossible. 3. Fixes due to bugs not related to your original issue are not required to use your stored procedures in order to fix data. 4. Understanding the nature of your database becomes easier for someone who has never seen your system. 5. It is documentation of how your data fits together. To sum it all up, in a bug free world, I would only flinch at the idea of not having referential integrity. You might be able to have a faster system due to your knowledge of the data and where indexes are needed as well as when something needs to be checked for validity, but a little bit more hardware seems worth the extra guarantee of data integrity. Due note, to me their are few things worse than trying to figure out how bad data got into the system, and how to correct the problems it introduced to the rest of the system.. Will >===== Original Message From "David Henry" <henryd@net-gong.com> ===== >Assuming: >1. All application access to my database is via stored procedures. >2. My stored procedures can be relied upon to do sanity checks regarding >relationships between tables > >then is it really necessary to define constraints? Isn't that just an >unnecessary overhead and just duplicating the work of my sanity checks? > >Your thoughts would be appreciated. ------------------------------------------------------------ This e-mail has been sent to you courtesy of OperaMail, as a free service from Opera Software, makers of the award-winning Web Browser, Opera. Visit us at http://www.opera.com/ or our portal at: http://www.myopera.com/ Your free e-mail account is waiting at: http://www.operamail.com/ ------------------------------------------------------------