2013/7/24 Aaron Abreu <abreual@bay.k12.fl.us>:
> a NON-technical version...
>
> st.procedures and automation are great...
>
> but...
> sounds like everybody is dancing around the main theme..
> so lets say it....
> that dreaded word that developers and DBA's cring to hear...
> the one part of our job that we all hate...
>
> DOCUMENTATION !!!!!
>
> My worst fear is simply this...
> having to fix something somebody else wrote.. and they
> are not there anymore..... and the only documentation is the code itself..
> been there... on a few occasions just had to write something new...
>
>
>
>
>
>
> On Tue, Jul 23, 2013 at 7:29 PM, Some Developer <someukdeveloper@gmail.com>
> 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?
The same applies to tables, triggers and so on.
The point is that you need to spend time in any case, only that most
of us feel more comfortable with tables than with procedures.
But a (modern) database is a mix of tables, grants, schemas and, of
course, stored procedures.
We need to cope with all of them.
And, please, don't top-post.