Hi,
I personally see no central role in P5EE for stored procedures.
I am assuming the flurry of discussion on stored procedures is because
it is of interest to Perl enthusiasts to see Perl being used in
unique ways.
Stored procedures are usually used for several things:
1. embedding business logic in the database
2. enforcing various forms of referential integrity not natively
supported by the database (i.e. delete->cascade, etc.)
3. improving performance for simple transactions
(the actual SQL is precompiled)
1. This is terrible for the P5EE principle of making business logic
which is anywhere in the Enterprise being available everywhere
across the Enterprise. Business logic should never be stored in
the database because it hides it from being accessible elsewhere.
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.
3. This line of reasoning has always seemed overrated to me,
perhaps because it is most promoted in PC-to-DB client-server
systems (perhaps with slow ODBC drivers) and I have always worked
directly on the server. However, I believe that the most useful
level of abstraction for data access (as in P5EEx::Blue::Repository)
is at a logical layer. Thus, if implementations of the Repository
choose to use stored procedures, that is their business. The primary
implementations of the Repository interface will use SQL.
Again, the use of stored procedures is not central to or a requirement
of the P5EE that I envision.
Stephen
At 04:28 PM 2/28/2002 -0500, Perrin Harkins wrote:
>All this talk about stored procedures in Perl makes me wonder. Aren't
>stored procedures the kind of legacy architecture everyone is trying to
>get away from? Aren't clustered application servers (like mod_perl +
>selected modules) a better approach in general?
>
>I usually hear people support stored procs by saying that they are
>cross-language, but so is SOAP and HTTP. So why is everyone so hot to
>code stored procedures?
>
>- Perrin
>
>
>
