Re: Re: DRY for ActiveRecord w/PostgreSQL : defaults and validations

Alex Young
Mon, 19 Sep 2005 11:56:55 -0000

Nicholas Van Weerdenburg wrote:
> There has been a few long threads on the philosophy of dbms
> constraints versus application-logic constraints. IIRC correctly,
> application-logic validation was the philosophical direction, being
> DHH''s preference.
>
> Part of the influence on this was, I think, MySQL''s only rather
recent
> support of constraints in the DBMS.
>
> The other was that an OO domain model can be hard to constrain in a
> RDMS constraint model.
>
> Nick

My view on this (for what it''s worth) is that DBMS constraints should
be
used if they''re available, but that it should be possible to put them
in
the application if not - ideally, this should be an transparent
fall-back, but I can see that breaking in lots of nasty ways.  My
reasoning is that the DBMS constraint code is much more mature (in
general), and therefore likely to be far better tested, than new
application-level code (with no disrespect intended to its authors,
naturally).  It''s also likely to be more efficient, but that''s
a
tangential issue.

Going the other way, it would be *extremely* nice if the DB wrappers
could push AR-defined constraints down to the DB level if it detected
that they were available (ALTER TABLE... et al), but signal back that
they were not if necessary, so that AR could handle it at the
application level for those running on a feature-poor backend.

Am I totally off-base here?  I can''t help but think that being able to
say :dependent in AR is far clearer than having to say ''FOREIGN
KEY...''
in SQL, in part because you''re then defining the cascade in the same
place as the relationship itself, and with a possible push-down from the
wrapper layer, you get the best of both worlds.

Thoughts?  Comments?  Rotten fruit?  Pointers for where this might be
patchable-in?

--
Alex