Taking an absolutist position either way is pretty blind. What is the
purpose of the procedure? Is it enforcing business rules? Are these
rules that must be enforced against already existing data or are they
more akin to validation of a credit card. How many people are accessing
your database at one time? And most importantly, what are you best at?
Adrian Klaver wrote:
On 07/23/2013 05:29 PM, Some Developer 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 don't understand this argument. If you implement all of your logic in
the application then you need to make a network request to the database
server, return the required data from the database to the app server, do
the processing and then return the results. A stored procedure is going
to be a lot faster than that even if you just take away network latency
/ transfer time.
I'm in the middle of building a database and was going to make extensive
use of stored procedures and trigger functions because it makes more
sense for the actions to happen at the database layer rather than in the
app layer.
Should I use them or not?
Personally I figure the arguments for and against are closely
correlated with where on the development chain you are, and are tied
in with job security. If you are an app developer than it is in your
interest to have code in the app, if you are a database developer in
the database. Me, I am tend to go with your argument about keeping
procedures, where appropriate, in the database for the reasons you
state. In other words an API in the database.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
