I think the strongest argument for or against an ORM is that it changes the structure of your code, how you reason about your data.

Things like performance, ease of use, reusability, schema generation etc are minor points and not the big issue you need to think about.

Personally I feel that an ORM will lead your project in the wrong direction and your database schema will suffer.

ORMs will usually mix both reading and writing within the same class, but those are not the same thing.

Readers will have different views of your model depending on who they are or what time it is. Writing on the other hand must fulfill your constraints.

Other common mistakes of ORMs is mapping one class with one table, but your data consist of series of relationships, that can’t be explained with a class.

An ORM creates an illusion that your data is actually the class entities in your repository. This can have the effect of creating constraints in your own mental model of your data, thus making it harder to evolve your schema because you are to fixed on how your classes are designed.

Great comment! I’ve been thinking about a tangentially related subject:

TypeScript is like a relational database (and other structural statically typed languages) of your application behavior, allowing you to query the current possible states of your data at any given point in your application code.

I’ve been thinking about this more since TypeScript got template-string generics, and folks have experimented with eg type-checking SQL strings back into application code.

This is the piece that draws me to an ORM: that it brings the “relational model” into application code, NOT the “object” part of an ORM.

Does anyone have any opinions about which language ecosystems create the most effective type-mappings between a RDBMS and application language?

Part of me also wonders if there’s a ton of time lost on mapping between languages like this when the tooling that’s really missing (afaik) is better tooling for producing, consuming, and generally interacting with SQL and db schemas as the data runs through your application pipeline.

> We've recently switched from JavaScript based querying code to mostly raw SQL

Curious what your use case is, because in every codebase I've worked on, people pretty quickly get tired of writing out SELECT * FROM [table] WHERE id=? and UPDATE [table] SET field=? and looping over database cursors all day, and you end up with a half-done, buggy non-ORM.

We're using knex.js, so we're not messing around with database cursors (we get an array of objects), and we don't have to write out the columns for inserts/updates. We also sometimes use the knex query builder for super trivial selects from a single table.

But for anything more complex than that (e.g. SELECT queries joining several tables) we're using knex.raw so the query itself is raw SQL where we're very much thinking in the relational model rather than in terms of objects.

Ahh that makes more sense. My preference has been to use an ORM for your normal CRUD, but write more advanced queries using SQL (or sometimes just write the where clause using SQL, if the select is otherwise simple.) I am not a fan of query builders.