[spacemanmatt]

> but I wonder how often it comes into play.

Databases are not interchangeable, though sharing a common query language makes the skill set somehat interchangeable. I think this is part of the nuance often lost in the discussion of ORMs and database-portability.

I have worked with many developers who actively deny this basic reality, in favor of trying to bury all that variability under an ORM, rather than exploit any of the proprietary features. I understood it as a crutch when I was still in the flat part of that learning curve, but I am a lot happier building a rich SQL application interface (non-ORM!) these days.

[mercurial]

> Databases are not interchangeable, though sharing a common query language makes the skill set somehat interchangeable. I think this is part of the nuance often lost in the discussion of ORMs and database-portability.

I see two realistic reasons for why having an ORM/avoiding DB-specific queries is good idea:

- your product supports multiple databases

- you want to use something like sqlite in memory for tests

[spacemanmatt]

> your product supports multiple databases

In this case, I tend to see pretty light loads. You can do this with fairly vanilla (ORM-generated) SQL and design. When your business begins to lean heavily on the database for operations (I saw this in finance) around the clock, and you have to start being more judicious about your queries, these applications are usually the first to buckle.

> you want to use something like sqlite in memory for tests

Only if I have to support sqlite in the field!