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.
>
>>
>>
>
>
