At 05:50 PM 2/28/2002 -0600, Dave Rolsky wrote: >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.
If we relied on referential integrity capabilities enforced in the database, how would our application be portable to MySQL? Files? BerkeleyDB? Remote data stores accessed via SOAP? Repositories on legacy data storage? Real-time data collected from the operating system? I understand that there are engineering tradeoffs in every design decision. In a project where you could rely on having a particular relational database, it might make sense not to take the stand I have taken. That is not the position that P5EE is in. I consider that portability is one of the highest priority Attributes of Enterprise Systems for P5EE to support. So in my vision of P5EE, stored procedures may be tolerated, acknowledged, and worked with, but not relied on. It should also be noted that once there are high-level/logical object servers (Entity Widgets) and repository servers (Repository) implemented in Perl, this represents a much richer resource than stored procedures for other languages to tap in to via SOAP or CORBA (I would place my bets on SOAP/mod_perl/Apache, thank you). Stephen
