On Thu, 28 Feb 2002, Stephen Adkins wrote: > 2. Referential integrity which is enforced by the database is the > DBA's defense against buggy programs. Correctly written programs > should never trigger a referential integrity violation, and they > should *never* rely on their existence to assist in their own success. > (i.e. Delete->Cascade) (The program should delete child rows > explicitly before deleting parent rows if that is required, > without relying on the database to do that for them.) > Thus, the P5EE approach should be to build application logic that > would work with or without referential integrity constraints placed > on the database, and the DBA's can put them in if they want.
This sounds like crazy talk to me, buddy. Ideally, the database should handle referential integrity so that you can use the database from multiple languages/apps/whatever without having to duplicate the referential integrity maintenance code. This is an entirely separate issue from putting business logic into stored procedures, which I dislike for some of the reasons you mentioned. -dave /*================== www.urth.org we await the New Sun ==================*/
