I am in the camp that subscribes to the idea that the best tool for the job should prevail. If you are working on a project that will become open source, then yes... you may want to keep database transactions within the application code domain. But in my experience, there won't be a lot of switching of backend databases after initial release (vendor licensing, client's requests, etc.)
The efficiency gained by stored procedures is too great to pass up when performing heavy DB data processing. Create statements for the stored procedures can be managed in the same code repository as the application code itself making code management a breeze.
It's nice not having to worry about your backend persistance layer, but if you plan to provide a robust, efficient and "snappy" solution to your client you should become familiar with ALL aspects of the solution including the persistance layer.
I am in the camp that subscribes to the idea that the best tool for the job should prevail. If you are working on a project that will become open source, then yes... you may want to keep database transactions within the application code domain. But in my experience, there won't be a lot of switching of backend databases after initial release (vendor licensing, client's requests, etc.)
The efficiency gained by stored procedures is too great to pass up when performing heavy DB data processing. Create statements for the stored procedures can be managed in the same code repository as the application code itself making code management a breeze.
It's nice not having to worry about your backend persistance layer, but if you plan to provide a robust, efficient and "snappy" solution to your client you should become familiar with ALL aspects of the solution including the persistance layer.