When *not* to use an O/R Mapper?

A couple situations I can think of (and correct me if I am wrong) are:
1. You app is too small (and not going to scale up), and not worth the effort to use them. Refactor to use it when it needs to be.
2. You have an existing relational database that is way too big (many 50 million rows tables?), and try to build a new app on top of it.
3. Corporate culture restrictions

-----------------------------------------------------------------------------------------

Well, 1 and 32 are non-reasons, technically.

1: Your app is too small. Sure. Like the apps in the 70s were not supposed to be used long - which got sus the year 2000 problem. Small apps grow.
2: the amount of tables is irrelevant, as is the amount of data. What is interesting are the data access patterns.

NOT using an O/R mapper is a good alternative if:

* you have relatively few business rules that
* are very simple and static (i.e. do not change often) AND
* you require high database throughput.

Good esxampels for this may be accounting for stock ttrades, or the core book keeping of a bank. hundreds of thousands of transactions, BUT - the basic rules of bookkeeping are trivial and have not changed for years.

Another good example where O/R mappers fail is everywthing which really gets a lot of advantages from a SET based manipulation approach. Liuke I was able to calculaate, years ago, in a bank, payback projections over 10 years into the future (do not ask why they needed this) over tens of thousands of outstanding grants (yes, not credits - government grants) in very few minutes by using three SQL statements - one being three pages long, printed.

This is stuf fthat basically an O/R mapper is not done to do, and where the whole object model is vastly inferior to the standard SQL set based approach.

Everything which is a standard OLAP application, which has complex business rules an ddoes not do data mass manipulation, is a O/(R mapper heaven.

And no, complexity of the app is NOT an issue. I take the same time (well, I am actually faster) making a simple object with the EntityBroker than I do with SQL - one object, one table, and I already save time, so why should I not use it even in a trivially small app?

--------------------------------------------------------------------------------
Thomas Tomiczek
THONA Consulting Ltd.
(MIcrosoft MVP C#/.NET)