3 ms·

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

by henning 19y ago

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

edw519 19y ago
"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.
- henning 19y ago
  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.
  - pyroman 19y ago
    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.
  - justindz 19y ago
    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.
nradov 19y ago
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.
- henning 19y ago
  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.

3 ms·

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

by henning 19y ago

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

edw519 19y ago
"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.
- henning 19y ago
  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.
  - pyroman 19y ago
    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.
  - justindz 19y ago
    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.
nradov 19y ago
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.
- henning 19y ago
  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.