Rails doesn't scale because RI/transactions in app not db!

Rails
21

I’ve come up with a pretty simple strategy. Constraints like NOT
NULL, length, etc are handled by my app. They’re really easy to test,
often change a lot, and over all are easier when managed by my app. I
use foreign key constraints because my RDBMS is meant to handle
relations.

When you really understand how Oracle (perhaps other databases too?)
optimizes its SQL query plans, adding a not null constraint to a
column can help the optimizer take a better path to getting you the
data you want. The more information you give the database, the better
chance it has of doing its job in the optimal way.

22

You do. That’s the point.

And it is a point that Pick, and to a certain extent OS400, worked out
decades ago.

For some reason nobody ever integrated the DBMS into the Unix
filesystem. Instead we have bolt on ones that duplicate a lot of what
Unix does already.

On May 31, 11:40 am, Lionel B. [email protected]

23

On Thursday 31 May 2007, stephen O’D wrote:

RI should be in the app - Apps come and go, 5 years ago it was a Perl
CGI app, then came PHP just before some pointy haired boss decided
J2EE was the way to go. I bet that in all this time the database
structure hardly changed at all. Lets not get started on all the
various back end processes that may need to talk to this database to
do their thing etc.

Apparently, no one has referred to these two (short) articles by Martin
Fowler yet

IntegrationDatabase
ApplicationDatabase

I’d say that Rails being opinionated considers databases to be the
property of their applications. As elsewhere in Rails, you can work
around this opinion, but conforming to it leads you on the path of
least resistance.

Regarding sharing database content, Rails has an opinion, too: Offer a
service to interact with this content. Doing so is the best way to
ensure that the rules of your domain are enforced. These rules can
hardly be expressed through referential integrity constraints alone.
So, unless you’re going to put all the business logic in the database,
a service looks like the right thing.

The database simply must protect the data -
constraints and foreign keys are the way forward here (I tend to
avoid triggers like the plague).

As I say above, I think it is quite questionable whether the database
can protect the data sufficiently using only these means.

All that said, I’m very much in favor of checking RI and NOT NULL in the
database. It’s not even particularly complicated. Have a look at

http://agilewebdevelopment.com/plugins/enforce_schema_rules
http://www.redhillonrails.org/

The only snag I can think of is that FK constraints can bite you when
loading fixtures for testing. AFAICT, when using foreign key
constraints, there’s currently no way to load fixtures containing
mutual references.

This problem might be solvable by changing Fixtures#create_fixtures so
that it issues

SET CONSTRAINTS ALL DEFERRED

(see PostgreSQL: Documentation: 8.2: SET CONSTRAINTS
to databases that support it. I haven’t tried this, however, and as I
don’t need it currently, I’m not going to investigate it right now. So,
if anyone wants to beat me at it, go ahead.

Michael

–
Michael S.
mailto:[email protected]
http://www.schuerig.de/michael/