> transaction processing. If I need to tie several pieces of
> functionality
> together in one database hit, then I'll put it in a stored proc. For
> example, I'm working on a nested set procedure right now, where I
> need to
> find the placement of siblings in a tree, relative to a passed in
> value, and
> then perform both and insert and an update. So, that's three queries
> that
> all need to run together - perfect place for a stored proc.
>
Great example. In that case I would choose a stored procedure as well,
but just for that case.
> For "security" alone? Yah, maybe if we had about three more people
> who did
> nothing but write the stored procs for us.
That is one of the negatives not mentioned so far. Stored procedures
simply take more time to write.
-Matt
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
