> Brady asks:
> > Why is this? ... If each SQL operation is well thought out, and coded
> > according to certain quality standards, there is very little different
> > to using stored procs.
>
> I agree that the quality level can be fine. The problem is that you're
> storing the lowest-level persistence *INSIDE* the next layer up doubles (at
> least) maintenance tasks. When data model changes occur, you've got to
> change dependent SQL in every relevant module.
using procs isn't going to change this. If you add a field to a table,
your insert proc needs to accept that and all call
code needs to be updated as well.
Inline sql strings, it's indeed a nightmare, as you don't get compile
time error messages that something changed. Though
things aren't 100% maintenance free if you use procs, not by far, it also
requires maintenance, like any other code which is faced
with changes. The goal is to find what to change early on so you can use
computer based checks (read: compiler) to find the areas
where you need to make changes.
FB
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
