6 ms·

I think there are 3 main reasons ORMs came into common use: 1. As a reaction to common SQL injection from poor libraries not implementing parameterized queries

I think there are 3 main reasons ORMs came into common use: 1. As a reaction to common SQL injection from poor libraries not implementing parameterized queries. (2004 or so) 2. Novice engineers not wanting to learn SQL (look I learned how to make a blog in RoR, and I like mongo!) 3. As a theoretical abstraction above the data-store (as though you might someday be able to switch the data-store beneath the ORM) 1 has been solved, 2 was never okay (point of the article), and 3 isn't really okay either because it's too leaky (performance specifics).

eru 9y ago
For 3: the proper abstraction for relational data is, surprise, a relation. I used to work in an environment where we had relations as full first class data structures. They are very pleasant to work with. We actually had 'relation-object-mappers', ie when we had to interact with other systems that didn't use relations, we often mapped them to relations internally to make them play nicer.
- yorwba 9y ago
  How were those relations represented? If I understand correctly, you were not just wrapping tables in a database, but using some other backing implementation. What were the most common operations, and what was the performance like?
  - eru 9y ago
    Oh, the implementation was fairly straight-forward. I think just sorted arrays are something. It wasn't about speed of execution, but expressiveness when coding. Later on they even added proper type system support. Common operations were things like map/project, extend, filter, join, collect-by-key / expand, etc. Just as Codd pointed out in his original papers, relations allow you to not have to make a choice about a hierarchy for your data. Using key-value store like a hash-table in your program, or the much vaunted has-a relationship between objects would force you to make these choices. Thus making interacting with the data awkward for all but one access pattern. Relations work best when your program is written in a style that deals largely in immutable data. (What we call 'purely functional', but people in dysfunctional languages have also picked up on the advantages recently.)
    - int_19h 9y ago
      > Just as Codd pointed out in his original papers, relations allow you to not have to make a choice about a hierarchy for your data. Or, alternatively, make it really painful when you do actually need to query hierarchies, along the lines of "give me all the tuples above this one in the hierarchy".
      - eru 9y ago
        Datalog can do those kinds of queries--transitive closures--easily, if memory serves right. Datalog is a specifically chosen subset of Prolog.
exclusiv 9y ago
I'd add #4 - it's just generally faster and more enjoyable to develop with a good ORM.
- andybak 9y ago
  Yep. Learned SQL. Happy never to have to touch it again.
- randomdata 9y ago
  Although, I think what you plan to do with the data also makes a big difference. Which probably explains why opinions vary so widely. For short-lived processes, like typical web applications and command line utilities – that load data from the database, do something with it, and then purge it from memory again – I'm becoming less and less convinced that ORMs are actually a benefit. On the other hand, if your application plans to map the database data to memory for long periods of time, with the need to keep them in sync, then you're probably going to end up writing something that resembles an ORM anyway, and poorly at that. In this case a good ORM is beneficial.
orf 9y ago
For 3: if you want to distribute a library or service and have no control over the data source.
pvg 9y ago
ORMs of various stripes were in common use well before 2004 so 1 & 2 don’t sound terribly persuasive. 3 is definitely an evergreen selling point - you might change to a different RDBMS vendor (back when there was such a thing), etc.
JamesBarney 9y ago
4. The pain in the butt of writing and maintaining your own mapping code. 5. Type checking all your queries. 6. In code query composability. But I totally agree that ORMs are too leaky of an abstraction for 2 to be really useful, and that 3 is much harder than it appears to be.
- pjmlp 9y ago
  DALs can be easily written with libraries like MyBatis, jOOQ, Dapper, .... Just because we are using SQL doesn't mean we have to do the mapping fully manual.
  - mattridley 9y ago
    I use jOOQ - I like the benefits of having the static type checking but the ease of expressing with a SQL like DSL. Plus it plays very nicely with kotlin :)
- pmontra 9y ago
  +1 for these three points. But I'm really surprised every time people tell me they look at the schema as defined into the ORM instead of at the table in the database. I'm really jaw dropped the few times I know somebody doesn't even know SQL, only the ORM. Maybe they look at it as if it were the reaction of somebody that thinks you must know assembly if you want to program Ruby, Python or Node (I don't.) Still, if you work with a database you must know it's internal language, SQL or NoSQL. Your going to need it or build a mess. And involving a DBA early in the project can make your database at least twice as fast, with the right schema and the right queries. Then you translate that into the ORM you want to use.
  - dizzystar 9y ago
    Woah, who are you interacting with that not knowing SQL is rare? In my experience, nearly no one knows SQL, and the attitude seems to be that learning it at all is a waste of mental bandwidth. On the other hand, I wonder if knowing none at all is better than knowing a little.
rickycook 9y ago
so, i think #3 is less useful for switching out the actual DB server itself in an ongoing project, but i’ve found it immensely useful in a couple of ways: - replaced the DB driver mid way through a project to a slower, but more complete implementation. this went flawlessly, because it’s all so generic and in the end the same DB under the hood, so a simple change (unless you don’t use an ORM where i could see it being a nightmare) - started a new project where i had to use MSSQL, which I’d never used before, but i’m a big fan of postgres/sqlalchemy. other than ODBC oddities, it was really simple to write the new app with all the same patterns i was used to with things like update on write, lazy joins, constraint deferral, and i think most importantly would be MIGRATIONS! huge help to have the same migration framework that i was used to
zimpenfish 9y ago
> As a theoretical abstraction above the data-store I worked on a project with a home-grown ORM (in C; it was horrible) that abstracted over both MySQL and Postgres ... except the overarching application required Postgres-specific column types and functions.

eru 9y ago

For 3: the proper abstraction for relational data is, surprise, a relation. I used to work in an environment where we had relations as full first class data structures. They are very pleasant to work with. We actually had 'relation-object-mappers', ie when we had to interact with other systems that didn't use relations, we often mapped them to relations internally to make them play nicer.

yorwba 9y ago
How were those relations represented? If I understand correctly, you were not just wrapping tables in a database, but using some other backing implementation. What were the most common operations, and what was the performance like?
- eru 9y ago
  Oh, the implementation was fairly straight-forward. I think just sorted arrays are something. It wasn't about speed of execution, but expressiveness when coding. Later on they even added proper type system support. Common operations were things like map/project, extend, filter, join, collect-by-key / expand, etc. Just as Codd pointed out in his original papers, relations allow you to not have to make a choice about a hierarchy for your data. Using key-value store like a hash-table in your program, or the much vaunted has-a relationship between objects would force you to make these choices. Thus making interacting with the data awkward for all but one access pattern. Relations work best when your program is written in a style that deals largely in immutable data. (What we call 'purely functional', but people in dysfunctional languages have also picked up on the advantages recently.)
  - int_19h 9y ago
    > Just as Codd pointed out in his original papers, relations allow you to not have to make a choice about a hierarchy for your data. Or, alternatively, make it really painful when you do actually need to query hierarchies, along the lines of "give me all the tuples above this one in the hierarchy".
    - eru 9y ago
      Datalog can do those kinds of queries--transitive closures--easily, if memory serves right. Datalog is a specifically chosen subset of Prolog.

exclusiv 9y ago

I'd add #4 - it's just generally faster and more enjoyable to develop with a good ORM.

andybak 9y ago
Yep. Learned SQL. Happy never to have to touch it again.
randomdata 9y ago
Although, I think what you plan to do with the data also makes a big difference. Which probably explains why opinions vary so widely. For short-lived processes, like typical web applications and command line utilities – that load data from the database, do something with it, and then purge it from memory again – I'm becoming less and less convinced that ORMs are actually a benefit. On the other hand, if your application plans to map the database data to memory for long periods of time, with the need to keep them in sync, then you're probably going to end up writing something that resembles an ORM anyway, and poorly at that. In this case a good ORM is beneficial.

orf 9y ago

For 3: if you want to distribute a library or service and have no control over the data source.

pvg 9y ago

ORMs of various stripes were in common use well before 2004 so 1 & 2 don’t sound terribly persuasive. 3 is definitely an evergreen selling point - you might change to a different RDBMS vendor (back when there was such a thing), etc.

JamesBarney 9y ago

4. The pain in the butt of writing and maintaining your own mapping code. 5. Type checking all your queries. 6. In code query composability. But I totally agree that ORMs are too leaky of an abstraction for 2 to be really useful, and that 3 is much harder than it appears to be.

pjmlp 9y ago
DALs can be easily written with libraries like MyBatis, jOOQ, Dapper, .... Just because we are using SQL doesn't mean we have to do the mapping fully manual.
- mattridley 9y ago
  I use jOOQ - I like the benefits of having the static type checking but the ease of expressing with a SQL like DSL. Plus it plays very nicely with kotlin :)
pmontra 9y ago
+1 for these three points. But I'm really surprised every time people tell me they look at the schema as defined into the ORM instead of at the table in the database. I'm really jaw dropped the few times I know somebody doesn't even know SQL, only the ORM. Maybe they look at it as if it were the reaction of somebody that thinks you must know assembly if you want to program Ruby, Python or Node (I don't.) Still, if you work with a database you must know it's internal language, SQL or NoSQL. Your going to need it or build a mess. And involving a DBA early in the project can make your database at least twice as fast, with the right schema and the right queries. Then you translate that into the ORM you want to use.
- dizzystar 9y ago
  Woah, who are you interacting with that not knowing SQL is rare? In my experience, nearly no one knows SQL, and the attitude seems to be that learning it at all is a waste of mental bandwidth. On the other hand, I wonder if knowing none at all is better than knowing a little.

rickycook 9y ago

so, i think #3 is less useful for switching out the actual DB server itself in an ongoing project, but i’ve found it immensely useful in a couple of ways: - replaced the DB driver mid way through a project to a slower, but more complete implementation. this went flawlessly, because it’s all so generic and in the end the same DB under the hood, so a simple change (unless you don’t use an ORM where i could see it being a nightmare) - started a new project where i had to use MSSQL, which I’d never used before, but i’m a big fan of postgres/sqlalchemy. other than ODBC oddities, it was really simple to write the new app with all the same patterns i was used to with things like update on write, lazy joins, constraint deferral, and i think most importantly would be MIGRATIONS! huge help to have the same migration framework that i was used to

zimpenfish 9y ago

> As a theoretical abstraction above the data-store I worked on a project with a home-grown ORM (in C; it was horrible) that abstracted over both MySQL and Postgres ... except the overarching application required Postgres-specific column types and functions.