I had asked the same question on Ruby on Rails list and following are the responses I received.
I think it's more along the lines of keeping everything in one layer. See this:
Choose a single layer of cleverness
I'm sort of coming around to that way of thinking. I switched from MySQL to PostgreSQL about two years ago and loved it. But now it DOES sound appealing to just handle stuff in Ruby/Rails instead of switching to pgsql for sprocs, constraints, triggers, etc. and then handling db errors that arise from them.
Pat replied to Joe saying:
This is one case where I have no problem being unDRY. The fact is that for the apps I write, my Rails app isn't going to be the only point of access to the DB. Most of the time the DB is there long before the Rails app anyway. So there are two ways of handling things that need checks, in my mind:
1. Write code to handle errors that pop up from the DB
2. Code the checks into the application itself
Sometimes it's easier and makes more sense to do #1. In Rails, you can achieve nearly all of the checks with one line of code, and everything else with just a few. You never even get to a point where the database would create errors.
Anyway this is getting slightly OT. Basically I just mean that I've got no problem having two layers of cleverness. It's necessary for me to have a clever database, and easy for me to have a clever Rails app. The Rails app never sees the DB cleverness, which only exists because other languages and people that access the DB aren't as bright.
Joe replied back:
Yeah, I'm redundant in this too. I've started using runner scripts more to interact with models, but I still do a lot of interfacing via psql and phppgadmin and not having data integrity protections in place at that level would be playing with fire. They haven't interfered with Rails or gotten in the way - things like validates_uniqueness_of happen before a unique key in postgresql can generate an error.
As far as my thoughts are concerned, I completely agree with Markus above and those who have posted in the favor of MySQL having advanced functionality like Stored Procedures.
MySQL is not "a little kid" anymore and MySQL DBA's would like for it to be realized so folks like Lee Asher won't wrongfully bash MySQL for not having these features.