Francis C. wrote:
constraints and you will need to transmit this knowledge outside of the
data model.) Generally speaking, is that all right with you?
It’s clear that RoR favors a style in which the data are defined along
with the application- that’s a clear bias of the framework- but are we
also saying that databases are to be considered purpose-build components
for specific applications? Just curious what people’s opinions are.
For why RoR is like it is, see David Heinemeier H.'s blog post,
“Choose a single layer of cleverness”:
in which he says:
Christopher Petrilli voices a frequent misconception about Active
Record, the ORM of Rails, in Least common denominator. The thinking goes
that MySQL is holding us back from taking advantage of more advanced
database features available in PostgreSQL, Oracle, and others. That if
only MySQL was more clever, had more features, we would be embracing
them with open arms. Wrong.
Active Record is opinionated software, just like the rest of Rails. This
is a matter of opinion, not constraints. And the opinion goes as
follows: I don’t want my database to be clever! Keep those crayons
firmly in place, please.
Unlike Christopher, I consider stored procedures and constraints vile
and reckless destroyers of coherence. No, Mr. Database, you can not have
my business logic. Your procedural ambitions will bear no fruit and
you’ll have to pry that logic from my dead, cold object-oriented hands.
Before the DBA-induced side of your brain explodes at that statement,
please do read Martin F.'s article on the difference between
application and integration databases. And realize that my opinions are
confined to dealing with application databases (and that doing
integration through the database belongs in a time where Beverly Hills
90210 was a hit show on TV). Hopefully that calmed you down again.
In other words, I want a single layer of cleverness: My domain model.
Object-orientation is all about encapsulating clever. Letting it sieve
half ways through to the database is a terrible violation of those fine
intentions. And I want no part of it.
All that being said: Whatever floats your boat. Active Record is
surprisingly forgiving of your transgressions if you choose to hang out
at the Peach Pit. As long as you’re not banking your savings on a hope
we’ll change our ways once MySQL “grows up” and adds all these
Enterprise Features to become something bigger and better than a “toy
project”. You’ll die poor, then, I tell you.
The Martin F. article he refers to is here:
Having said that, very many Rails users (including Dave T. )
value having referential integrity enforced at DB level, and it is
usually the case that DHH is happy for others to extend Rails (via
plugins) to cover uses he isn’t personally interested in.
 In a footnote in the second edition of AWDR Dave T. writes:
"Many Rails developers donâ??t bother specifying database-level
constraints such as foreign keys, relying instead on the application
code to make sure that everything knits together correctly. Thatâ??s
probably why Rails migrations donâ??t let you specify constraints.
However, when it comes to database integrity, I (Dave) feel that an
ounce of extra checking can save pounds of late-night production system
debugging. You can find a plugin that automatically adds foreign key
constraints at http://www.redhillconsulting.com.au/rails_plugins.html.