One is not better than the other. They are different.
Sometimes it's better to say that the API point of compatibility is the
database and its stored procs, and sometimes it's better to say that the API
point of compatibility is a data access layer. They both have advantages and
disadvantages, an
I said:
> When data model changes occur, you've got to
> change dependent SQL in every relevant module.
Frans replies:
> using procs isn't going to change this. If you add a field to a
> table, your insert proc needs to accept that...
True, and for Updates as well. But SELECTs far outnumber those
> 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 persis
I think the crux here is keeping your SQL out of your business layer, not
how you actually implement the SQL.
> 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 da
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
