From: Jason Roelofs <jameskilton@...>
Date: 2007-03-28T23:36:38+09:00
Subject: Re: On Enterprise Ruby

------=_Part_30504_20960661.1175092594781
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>
> http://www.loudthinking.com/arc/000516.html
>
> It's a post by DHH, primary author of the "opinionated" Rails code. Like
> it
> or not, he is a mover and shaker in the Ruby world and in this article he
> says, "...I consider stored procedures and constraints vile and reckless
> destroyers of coherence."


For the record, I do agree mostly with this blog post.  In terms of quick
development, and mostly in testability, stored procedures are evil. I've
worked in a complex integrated Oracle environment before, I'll just say that
it's something I will never, ever do again. Writing untestable code, of any
kind, is the one thing I absolutely HATE to do.

That said, I don't agree on the same stance for database referential
integrity. The database is in place to hold data and to make sure
relationships exist and are correct, and as such means have been put in
place (constraints, referential integrity) to help with this. I can very
easily see situations where multiple apps access the same database, so yes,
the database needs to know something about relationships (and this stuff
*can* be tested).

However, if your Rails application is the only one who will be hitting the
database, then constraints and RI can be used but are unnecessary.

Jason

------=_Part_30504_20960661.1175092594781--