Using the approach of requiring 100% of the database interaction to be done through stored procedures is actually a bad idea, I would say. The database should be for "storing" "data" (among the usual CRUD and ACID properties), not for storing procedures to encapsulate the entire database. A few reasons why this is a bad idea is:

• slow tests (assuming you are writing tests)
• possibly harder to test (assuming you are writing tests)
• potentially large effort required if switching DBMSs, or in other words perhaps being tied to a single DBMS vendor
• effort or even possibility of switching to some non-SQL-based vendor or mechanism to store data

However, you should also consider how "likely" or not that the above things may happen during the lifecycle of your project when making your decision.

Using the approach of requiring 100% of the database interaction to be done through stored procedures is actually a bad idea, I would say. The database should be for storing "data" (among the usual CRUD functionality and ACID properties), not for storing procedures to encapsulate the entire database. A few reasons why this is a bad idea include:

• slow tests (assuming you are writing tests)
• possibly harder to test (assuming you are writing tests)
• potentially large effort required if switching DBMSs, or in other words perhaps being tied to a single DBMS vendor
• effort or even possibility of switching to some non-SQL-based vendor or mechanism to store data

However, you should also consider how "likely" or not that the above things may happen during the lifecycle of your project when making your decision.