What's Wrong With ORM

[ti@lemonia.org]

(Sorry: thread/header loss)

Greg McCaroll suggested:
:
: * "if we put our business logic in the database it will be
: really hard to change databases in the future"
:
: * if you aren't using any features of your database why would
: you ever want to change database?

As Greg noticed, there are other features of databases besides supporting
business logic. You'd have to rephrase it as

> * If you haven't implemented business logic in your database
>   why would you ever want to change database?

And this just doesn't follow, because there are lots of reasons you might
want to port your software from one database to another, as well as lots
of reasons what might be difficult or go wrong. I suspect the closest the
argument gets to being true is

> * "If we do anything non-trivial at all with our database app, it'll
>   be really hard to change databases in the future, so we might as well
>   use business logic within the database if it's appropriate"

But that's neither the same as what Greg was claiming, not as clear cut.

More subjectively,

:  * software is more likely to change than business rules

I doubt that this is true.

I've lost count of how many times, within organisations, either
a) the implicit "business rules", about (say) whether a contact record
needs a valid email address in it, have evolved over time, usually with
manual workarounds (email address = "(no email address)"), to the chagrin
of those who've attempt to glue automated systems onto manually-maintained
data and found it full of crud;

b) the business rules are complex, weird, and full of exceptions. You can
attempt to capture & codify them, but this is slow & incremental, and you
end up with (perhaps) guidelines you can check your data against (eg. 80%
of contacts have a valid email address!). A relational database will
simply refuse to play ball if a criterion isn't met.

This will sometimes be the wrong approach, at which point either you put
the business logic within the app, or devise some way of getting warnings
out of the logic within the database.

HTH

ti'