On 10/27/05, David Heinemeier Hansson <david.heinemeier / gmail.com>
wrote:
>> Ah ... but at that point, in many ways, he's wrong. The moment you
>> have data to migrate, there's a second program working on the
>> database. Unless -- as appears to be the case with Rails at this
>> point -- your migration is done using the exact same database access
>> layer as your primary application, you will get garbage data at some
>> point.
> To quote from the article (especially the "my opinions are confined to
> dealing with application databases"):
>
> [...]
>
> But it was my fault. I should have decorated that caveat with
> underline, bold, and possibly blink.

David, for what it's worth, I have more of a problem with how most
people misinterpret what you've said than what you've said. Having
discussed it with you in person, I understand where you're coming from.

> So actually we're very much in agreement. My strong opinions on this
> matter are strongly scoped. What we might agree on is whether that
> scope is a desireable one or not.

If you can guarantee that a particular database is only going to be an
application database, then I think that the scope is somewhat desirable.
In my experience, though, business people come to realise the overall
value of the data in that database and start wanting additional ways of
getting, manipulating, and reporting on that data. I have experienced
cases where single-purpose databases have become multi-purpose.

What I *fear* is that while Rails encourages good program design, it
ends up encouraging bad database design at the same time.

> And to further the group hug, I'm pretty neutral about foreign key
> constraints. It's triggers, business constraints ("don't insert if
> balance > 100"), and stored procedures that deserve the "Evil" label.

Yeah. I'm a cheerleader for foreign keys and hate that my embedded
database of choice (sqlite) doesn't support them in any way. There are
times when business constraints can be useful -- but the "proper" way of
doing that would actually be to abstract the relational information one
level further (e.g., if something can only be 'y' or 'n', then there
should be a *table* with a FK that contains the 'y' and 'n' values).

I will argue for the pushing of business logic into the database when
you hit an integration database stage or possibly access the data
through multiple mechanisms (perhaps in different languages) just so
that you don't violate DRY.

But by and large, most people put too much business logic in the
database.

-austin
--
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca