On Wed, Jul 24, 2013 at 2:29 AM, Some Developer <someukdeveloper@xxxxxxxxx> wrote: > I've done quite a bit of reading on stored procedures recently and the > consensus seems to be that you shouldn't use them unless you really must. I believe because most developers are not DBAs, and therefore are scared about something they cannot control. Placing as much logic as possible in the database is, in my opinion, good since it will prevent any accidental (?) connection to the database to corrupt your data. By accidental connection I mean a developer/dba connecting to the database to change some value and corrupting some constraint (that reside in the application) or by an aside application or a refactoring of the application (e.g., in order to change the application technology). Thanks to the PostgreSQL support to many pl languages, you can even reuse some existing application logic into the database, but it does not mean this is the smarter choice (performance? OOP vs procedural?). Of course, as placing business logic into the database makes the database "code" more complex, it is required to do unit testing on the code itself (e.g. pgtap). Finally, another point in being "scared" of using stored procedure is portability: a lot of frameworks claim to be portable across database because they use a minimal survival subset of SQL features that are almost supported on any decent database. Using a stored procedure will make more complex the portability, since pl procedures need to be translated from one database to another. Luca -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
