Lynn Pettis (3/11/2013)

---

fmuzul (3/11/2013)

---

Lynn Pettis (3/11/2013)

---

In addition, if the underlying table structure changes but the output of the stored procedures remains the same, you isolate the changes to the database. You modify the stored procedures to use the new table structures ensuring that the input and output of the procedures remains the same, the application does not need to change.

Replace "stored procedure" with "C++ procedure" and swap "application" with "database" and you get a perfectly valid statement again.

If you work with s.p., you isolate the changes to the database. And this can be good if you don't want to change the application.

If you work with the application language, you isolate the changes to the application. And this can be good if you don't want to change the database logic (or even don't want to have logic at all in the database).

DBAs obviously tend to prefer s.p. because they are accustomed to them.

Developers should prefer to avoid s.p.

You are operating under a false perception of me. I am not a DBA. I am a DBA/Database Developer/Developer. I have worked on all sides of the application. My perception comes from that experience.

If your application needs to support multiple database backends, then develop those database backends separately. Support the multiple code bases needed. Make use of the capabilities of each of those DB Engines to get the most from them to improve the performance of the application using those DB Engines.

There is a fallacy of truly portable code. I don't write Standard SQL code, I write code that makes the best use of the underlying DB engine. This provides a performant system upon which an application can be built.