Hacker News Reader

Comment by henning | Hacker News Reader

See "choose a single layer of cleverness" at http://www.loudthinking.com/arc/2005_09.html (can't permalink because he partially recovered from a crash).

View on HN

That's all well and good if you have a single layer of business logic operating on a particular database. But in the real world you may have multiple completely separate pieces of business logic, often written in different languages. It that situation, the database itself becomes the only place to put shared code to ensure that rules are followed.

This is where Martin Fowler's distinction between application databases and integration databases comes in. If your app is the only one hitting the database, things are much simpler.

"I consider stored procedures and constraints vile and reckless destroyers of coherence."

Finally. Someone comes up with a technical description of how I've always felt. Thank you, dhh.

I don't totally agree with him. I draw the line at stored procedures, triggers, and views; he draws the line at, uh, any relational integrity at all. I think database constraints are good to protect against application bugs.

I wonder why he uses a relational database at all if he's really just using it as a bit bucket.

I read his post and the one he linked to. It's an interesting argument. I've found great usefulness with views and triggers. When working with multiple developers that might mess with your models, I like to have overall control by being the database guy. That is where I am coming from.

Pointing to the fact that a lot of apps being built on Rails/Django/etc. (but not all of them) make sense with something like a doc-oriented DB.

Reply on news.ycombinator.com