Jim Cromie wrote:
[snip Virtues of SP - agreed :) And I have more opinions on the
drawbacks of SP, as expected... ]
>
> Drawbacks of SP:
>
> 1) Secondary BL mechanism - Referential Integrity is generally regarded as
> better. Its declarative, so is easier to use in the query optimizer.
Triggers can certainly be _procedural_.
>
> 1) Sub-Optimal location for Business Logic
>
> Business Logic kinda goes with Business Applications; Apps are the context
> and cause for BL, and probably the most natural place to define it,
> particularly since the App tends to be more OO than RDBMSs..
Having BL in the BA level means there must be a BA for things to work.
Migration path isn't critical for businesses; production databases are
seldomly moved. So this is more of an issue for the application vendors
than the database administrators (they want to sell the product, of
course :P).
>
> 2 concrete contexts from Perl world.
>
> DBI->prepare_cached($sql-cmd): method implies that it is stored for speed.
This statement only works _as_advertised_ w/ databases that have SP.
Note DBD::Pg states that Postgresql does not have a prepare concept
(it's there for compatibility, w/ the complete query sent every time).
That's why SP rocks :)
Regards,
yin-so chen