All
> Joe Breeden queried:
>
> >>It would be interesting to know how other people have solved
> >>that problem.
> >>Currently, we are essentially using embedded SQL in our apps.
>
> I have found that stored procedures + perl module wrapper around the
procs.
> is a nice, balanced approach.
Definitely; sotred procedures are hit-and-miss in a lot of environments.
Remember that a large number of people in the mod_perl world can't use 'em
because they (we) use MySQL. If one wanted to emulate this behaviour with
MySQL, you would essentially clone the functionality of your stored
procedures using Perl + DBI inside your persistence layer. That is a
perfectly viable approach too, but a lot less efficient than stored
procedures (many roundtrips versus one).
> The procs. give a nice performance boost as they are precompiled into the
> server (we use Sybase). I believe that they are more secure, in that you
> aren't dynamically generating sql that might be 'hijack-able'. You are
> providing a discrete amount of functionality. Placing the stored procedure
> execution code in a perl module makes for easy/clean perl access from the
> rest of the app. Moving to a new db isn't too terribly difficult in that
the
> proc names will probably remain as well as the parameters that you pass.
> Also, how often do you move to another database in the life of a web app
> anyway (at least in our corporate environment)?
True, although I don't think it's uncommon to want to move from MySQL to
Postgres, for example. I have also seen a lot of places move away from
MySQL up to something like DB2 or Oracle when they get their
"it-all-has-to-be-spent" venture capital infusion.
Sigh.
Kyle
Software Engineer
Central Park Software
http://www.centralparksoftware.com
