6 ms·

Here we go again. I'm pretty sure I've seen this post here (and the famous Vietnam of Computer Science one) several times before. No database access abstracti

by ericflo 15y ago

Here we go again. I'm pretty sure I've seen this post here (and the famous Vietnam of Computer Science one) several times before. No database access abstraction is going to be great for all situations. Whether it's object-oriented, functional, or DSL-based, there are going to be situations where it's frustrating to use. However, each of these abstractions have a purpose and a clear benefit for a certain subset of situations, or else they likely wouldn't have been created. Since people find some abstractions useful for some subset of situations, why waste so much time and energy fighting against its use entirely--labeling it an "anti-pattern"? On the other hand, why waste time and energy arguing for its ubiquitous use? Like with all other technology choices, the right prescription is to use an abstraction when it makes sense, and to abandon it when it does not. Maybe it would be more constructive to frame the discussion in this way: what cases are ORMs useful for, and what cases are they bad at? How can we identify the good use cases from the bad? Which use cases seem to be good uses but turn out to be bad, and why? What are alternative solutions for those bad use cases? Are there different philosophies of ORMs with different tradeoffs? What are those philosophies and tradeoffs and how can we choose which one most suits our problem?

div 15y ago
It feels like people keep getting burned by investing all their stock into an ORM and then overcompensate by never wanting to use any ORM again. ORM's are awesome to get things done quickly, but as stated in the article, and stated by those very same ORM's, you do sacrifice some performance. As usual with these articles, there is a false dichotomy that one should choose between ORM or no ORM. It's a perfectly sound decision to use an ORM and hand-optimize whenever the need arises. Also, ORM's usually _are_ optimized for the 90% use case, so going of on your own to write those in plain sql for your entire domain model is passing up on a huge amount of leverage.
- gaius 15y ago
  ORM is like satnav in your car. Sometimes it will get you from A to B without you having to think too much. But sometimes it will send you off around the houses. Now a normal person would say "stupid satnav" but an ORM fan would say "stupid car" (blame the database for being slow).
  - pyre 15y ago
    I don't see anyone arguing that the database is stupid for being slow. I see a bunch of anti-ORM people arguing that an ORM is never the right solution to any problem ever. I also see a bunch of people arguing that ORM mixed with SQL is perfectly fine and there is nothing 'broken' about it (which I think is the more moderate view). I don't see anyone here arguing the opposite extreme of "ORM is always the right approach to every problem." I view the "ORM fan" as a strawman for the most part in this whole discussion.
    - gaius 15y ago
      My experience as a DBA is that someone will develop using Hibernate, it'll go into production and run like a dog, and they'll go straight to their manager and say "It's the database". Because noooooo it couldn't be his perfect code, could it?
      - pyre 15y ago
        So ORM should never be used because it might be used by some incompetent programmer somewhere and frustrate his DBA?
        gaius 15y ago
        Sure. It's just a coding standard like any other. Enforce it the same way you enforce unit test coverage.
        pyre 15y ago
        So your argument is: It is possible for someone to improperly use X, therefore X should be banned.
- Ingaz 15y ago
  >>you do sacrifice some performance You sacrifice not only performance. You sacrifice power over data. ORMs - OK if CRUDs are your '90% uses cases'. ORMs - fail if you need something slightly more complicated.
  - div 15y ago
    There's still a relational database there that will respond just fine to any well-formed sql statements you can throw at it.
kunley 15y ago
ORMs are useful for one thing for sure: for making an illusion that OO way of thinking and relational way of thinking fits. But they don't fit really! I like the way original author explained it: the problem was that people were forced or convinced to use wrong abstractions. Due to the massive marketing of really big players since 80s, relational databases are everywhere around; most of developers during the years took for granted that they MUST use SQL, so they stopped thinking if they really need relational model. Luckily we have other setting these days. There are plenty of production-ready non-relational database engines. To simplify your application layer and really map your OO data, please do use document database - they fit. That's it. No amount of pretending will dissolve the differences between relational model and object-oriented model. If in doubt, please go back to the theory, to the computer science. You don't have to dig through tons of papers from 70s when relational model has had its peak of scientific evolution - you just buy yourself the CTM book and go through all the computational models with examples of the real code. Please do the lesson. Otherwise any discussion will be about habits and beliefs again, not about science and engineering. And - I hate to say it - most of the comments like "here we go again" are really about habits and beliefs. How sad. The foundation of our occupation is hard science and engineering. We strive to build better things based on such concrete foundation. By sticking to the thinking "OO + relations fit" we abandon this foundation and we are turning into believers of some cult created decades ago by the marketing people of the few companies everybody knows in order to massively increase sales of RDBMSs. This is not engineering. Please, put yourself in the distance from the habits of using specific tools you're accustomed to; please think about it. [edit typo]
- div 15y ago
  Yes, there is an impedance mismatch in mapping data from relational data stores to object instances. This does not mean ORM's are an anti-pattern, or bad. ORM's provide a lot of value for the 90% use case that people often need to bang out under various time constraints (mvp, project for a customer, etc). There is a trade-off when using an ORM that you, or your team, should be aware of. Once you start hitting the limits of what an ORM can reasonably do for you, it's fine to either: - drop down to using handoptimized sql for specific queries / submodules of your project (e.g. a set of reporting pages) - figure out if you are trying to punch a cube through a circle by using a relational database over a nosql type storage, and consider moving part of your data to a different storage. I haven't had a lot of experience with nosql databases yet, but I think it's also interesting to consider that relational databases have been around for a long time, and alot of corner cases where they are unwieldy are known. Nosql databases are not as vetted against reality yet, so abolishing one for the other may amount to nothing else than trading one set of problems for another.
gaius 15y ago
what cases are ORMs useful for, and what cases are they bad at? That is covered in the article. ORMs are an advantage in the very early stages of a project, but a disadvantage in the later stages. Since a project by definition spends the least amount of its lifetime in the early stages, don't paint yourself into a corner!
- jvdongen 15y ago
  You (and the article) would be correct if the ORM/no ORM was a black and white affair. However, as others already pointed out in this thread, it is not. It is perfectly viable to use an ORM as the basis and gradually switch to 'raw' sql if the need arises. For most of my projects I use Django nowadays. Its ORM is usually sufficient. In cases where it is not I add a query method to a model class that just executes the most efficient sql query possible and returns the results in the most efficient format possible. For mature applications this can result in quite a lot of those query methods and the ORM than plays a lesser role. However, even in those case the ORM continues to be a convenience to me as a developer, e.g. because it powers the Django admin interface and because together with South (a database schema migration tool) it makes schema management a breeze. An ORM is a tool. And each tool has its own place and time. So, yes - there we go again ...
  - Luyt 15y ago
    "together with South (a database schema migration tool) it makes schema management a breeze." Thanks for mentioning this. I'm just learning Django, mainly for using its admin interface to avoid a lot of CRUD, and South seems just what I need to evolve my schema while I go along.
- davesims 15y ago
  Early vs. later isn't the problem. You can write n+1 queries in your first model or your 1000th. The problem is developers who don't know how to watch logs, don't know how to write efficient SQL, and projects that don't use adequate monitoring in general. If your ORM use is getting worse as you go, you probably need code reviews or NewRelic or better developers.
fauigerzigerk 15y ago
I think the "right tool for the job" argument is weaker than it appears. It implies that the job is fully defined before we start to model or even before we start to think about the problem. Application requirements may sometimes provide broad limits for technology choices but the link isn't very strong as there is a huge gap between the problem space and the solution space (evidenced by the army of software developers needed to translate between the two) Software is not hardware and it's not even engineering in my view. The extent to which we in the software space are able to define and redefine jobs as well as tools makes this kind of thinking useless.
- smharris65 15y ago
  Good point. Maybe you have to choose a tool that allows you to discard it if you find a better tool once the problem becomes clearer. So, the question is: are ORMs easy to "unplug" if you need to use a better tool?
  - Bootvis 15y ago
    If the requirements change outside of the scope of the ORM you can always write SQL to do the query or guide the ORM. If the requirement change requires a different backend using an ORM is actually easier, faster and less error prone. So yes.
  - dools 15y ago
    The problem with unplugging the ORM or inter operating is that the 2 biggest ORM frameworks are implemented such that they don't support composite primary keys and have stupid requirements like having an auto increment column called "id" on every table (including tables used as part of a many to many relationship!!). As far as I know Doctrine 2.0 absolves a lot of these problems but I've not used it yet.
japherwocky 15y ago
I think that right now though, conventional "wisdom" says to use an ORM for every web app. I like to see people push back on that; let's at least get to a state where we can consider dropping it from a project.

by ericflo 15y ago

div 15y ago

It feels like people keep getting burned by investing all their stock into an ORM and then overcompensate by never wanting to use any ORM again. ORM's are awesome to get things done quickly, but as stated in the article, and stated by those very same ORM's, you do sacrifice some performance. As usual with these articles, there is a false dichotomy that one should choose between ORM or no ORM. It's a perfectly sound decision to use an ORM and hand-optimize whenever the need arises. Also, ORM's usually _are_ optimized for the 90% use case, so going of on your own to write those in plain sql for your entire domain model is passing up on a huge amount of leverage.

gaius 15y ago
ORM is like satnav in your car. Sometimes it will get you from A to B without you having to think too much. But sometimes it will send you off around the houses. Now a normal person would say "stupid satnav" but an ORM fan would say "stupid car" (blame the database for being slow).
- pyre 15y ago
  I don't see anyone arguing that the database is stupid for being slow. I see a bunch of anti-ORM people arguing that an ORM is never the right solution to any problem ever. I also see a bunch of people arguing that ORM mixed with SQL is perfectly fine and there is nothing 'broken' about it (which I think is the more moderate view). I don't see anyone here arguing the opposite extreme of "ORM is always the right approach to every problem." I view the "ORM fan" as a strawman for the most part in this whole discussion.
  - gaius 15y ago
    My experience as a DBA is that someone will develop using Hibernate, it'll go into production and run like a dog, and they'll go straight to their manager and say "It's the database". Because noooooo it couldn't be his perfect code, could it?
    - pyre 15y ago
      So ORM should never be used because it might be used by some incompetent programmer somewhere and frustrate his DBA?
      - gaius 15y ago
        Sure. It's just a coding standard like any other. Enforce it the same way you enforce unit test coverage.
        pyre 15y ago
        So your argument is: It is possible for someone to improperly use X, therefore X should be banned.
Ingaz 15y ago
>>you do sacrifice some performance You sacrifice not only performance. You sacrifice power over data. ORMs - OK if CRUDs are your '90% uses cases'. ORMs - fail if you need something slightly more complicated.
- div 15y ago
  There's still a relational database there that will respond just fine to any well-formed sql statements you can throw at it.

kunley 15y ago

ORMs are useful for one thing for sure: for making an illusion that OO way of thinking and relational way of thinking fits. But they don't fit really! I like the way original author explained it: the problem was that people were forced or convinced to use wrong abstractions. Due to the massive marketing of really big players since 80s, relational databases are everywhere around; most of developers during the years took for granted that they MUST use SQL, so they stopped thinking if they really need relational model. Luckily we have other setting these days. There are plenty of production-ready non-relational database engines. To simplify your application layer and really map your OO data, please do use document database - they fit. That's it. No amount of pretending will dissolve the differences between relational model and object-oriented model. If in doubt, please go back to the theory, to the computer science. You don't have to dig through tons of papers from 70s when relational model has had its peak of scientific evolution - you just buy yourself the CTM book and go through all the computational models with examples of the real code. Please do the lesson. Otherwise any discussion will be about habits and beliefs again, not about science and engineering. And - I hate to say it - most of the comments like "here we go again" are really about habits and beliefs. How sad. The foundation of our occupation is hard science and engineering. We strive to build better things based on such concrete foundation. By sticking to the thinking "OO + relations fit" we abandon this foundation and we are turning into believers of some cult created decades ago by the marketing people of the few companies everybody knows in order to massively increase sales of RDBMSs. This is not engineering. Please, put yourself in the distance from the habits of using specific tools you're accustomed to; please think about it. [edit typo]

div 15y ago
Yes, there is an impedance mismatch in mapping data from relational data stores to object instances. This does not mean ORM's are an anti-pattern, or bad. ORM's provide a lot of value for the 90% use case that people often need to bang out under various time constraints (mvp, project for a customer, etc). There is a trade-off when using an ORM that you, or your team, should be aware of. Once you start hitting the limits of what an ORM can reasonably do for you, it's fine to either: - drop down to using handoptimized sql for specific queries / submodules of your project (e.g. a set of reporting pages) - figure out if you are trying to punch a cube through a circle by using a relational database over a nosql type storage, and consider moving part of your data to a different storage. I haven't had a lot of experience with nosql databases yet, but I think it's also interesting to consider that relational databases have been around for a long time, and alot of corner cases where they are unwieldy are known. Nosql databases are not as vetted against reality yet, so abolishing one for the other may amount to nothing else than trading one set of problems for another.

gaius 15y ago

what cases are ORMs useful for, and what cases are they bad at? That is covered in the article. ORMs are an advantage in the very early stages of a project, but a disadvantage in the later stages. Since a project by definition spends the least amount of its lifetime in the early stages, don't paint yourself into a corner!

jvdongen 15y ago
You (and the article) would be correct if the ORM/no ORM was a black and white affair. However, as others already pointed out in this thread, it is not. It is perfectly viable to use an ORM as the basis and gradually switch to 'raw' sql if the need arises. For most of my projects I use Django nowadays. Its ORM is usually sufficient. In cases where it is not I add a query method to a model class that just executes the most efficient sql query possible and returns the results in the most efficient format possible. For mature applications this can result in quite a lot of those query methods and the ORM than plays a lesser role. However, even in those case the ORM continues to be a convenience to me as a developer, e.g. because it powers the Django admin interface and because together with South (a database schema migration tool) it makes schema management a breeze. An ORM is a tool. And each tool has its own place and time. So, yes - there we go again ...
- Luyt 15y ago
  "together with South (a database schema migration tool) it makes schema management a breeze." Thanks for mentioning this. I'm just learning Django, mainly for using its admin interface to avoid a lot of CRUD, and South seems just what I need to evolve my schema while I go along.
davesims 15y ago
Early vs. later isn't the problem. You can write n+1 queries in your first model or your 1000th. The problem is developers who don't know how to watch logs, don't know how to write efficient SQL, and projects that don't use adequate monitoring in general. If your ORM use is getting worse as you go, you probably need code reviews or NewRelic or better developers.

fauigerzigerk 15y ago

I think the "right tool for the job" argument is weaker than it appears. It implies that the job is fully defined before we start to model or even before we start to think about the problem. Application requirements may sometimes provide broad limits for technology choices but the link isn't very strong as there is a huge gap between the problem space and the solution space (evidenced by the army of software developers needed to translate between the two) Software is not hardware and it's not even engineering in my view. The extent to which we in the software space are able to define and redefine jobs as well as tools makes this kind of thinking useless.

smharris65 15y ago
Good point. Maybe you have to choose a tool that allows you to discard it if you find a better tool once the problem becomes clearer. So, the question is: are ORMs easy to "unplug" if you need to use a better tool?
- Bootvis 15y ago
  If the requirements change outside of the scope of the ORM you can always write SQL to do the query or guide the ORM. If the requirement change requires a different backend using an ORM is actually easier, faster and less error prone. So yes.
- dools 15y ago
  The problem with unplugging the ORM or inter operating is that the 2 biggest ORM frameworks are implemented such that they don't support composite primary keys and have stupid requirements like having an auto increment column called "id" on every table (including tables used as part of a many to many relationship!!). As far as I know Doctrine 2.0 absolves a lot of these problems but I've not used it yet.

japherwocky 15y ago

I think that right now though, conventional "wisdom" says to use an ORM for every web app. I like to see people push back on that; let's at least get to a state where we can consider dropping it from a project.