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.
>
>
--
Adrian Klaver
adrian.klaver@gmail.com
