To me it sounds like you're talking about the argument of who has the responsibility of applying business rules, the application layer or the database layer - which is another entirely valid argument in itself, but distinctly different than the argument of whether to use an ORM in your application layer or not.
To a database person, the database is all about business rules: what we recognize as a "thing", what we record about these things, and how they relate to other things. ie, what are the facts about the business, and how do we reason about them?
Any conformant client code then must honor these rules, and oftentimes that means it must re-implement them, which is an acceptable cost if we have decided to use an RBDMS in the first place.
Now it's true, a given database may only implement a subset of all applicable business rules--maybe some fall outside the scope of the database, maybe it's preferable to offload some to a trusted client, maybe the business and database model have drifted apart over time, and no one wan't to overhaul the database model due to all the dependencies involved.
That said, any rules that the database does implement is a good thing, especially those simple rules that can be implemented as constraints. And it's good because then you can program against them, from any client, from any code, inside the database and elsewhere, and you can make guarantees about what possible states the data could be in. This is generally a useful thing.
Agreed. If the costs were equal, I would always implement business rules in the database. I doubt many people would disagree with that. The problem is, it takes longer to write and debug. However, despite this, I think there is a certain subset of rules the belong in the database without exception - constraints and things of that nature.
Would Reddit be a good example of this, where they use a relational database as a key/value store, don't use an off-the-shelf ORM and still depend on the application layer for all the business rules?
I admit I have no statistics, but it's been my experience that most places choose between a highly OO model + ORM and a highly relational model without.
> it's been my experience that most places choose between a highly OO model + ORM and a highly relational model without.
My experience has always been a highly relational model, ORM or not, and business rules enforced in app layer or DB (or a mix of the two). I've always seen them as distinctly different decisions.
Personally, in the past I was always a "rules in the app layer" guy, because of the many advantages of doing in that way, but as I get older the more difficult but guaranteed correctness of implementing in the database is becoming more appealing (especially if it's not me that has to actually write the code!!)
