7 ms·

I don't understand where this ORM 'divide' is coming from. ORMs are powerful, because they let you say less and do more. For 90% of the queries out there, an O

by debacle 15y ago

I don't understand where this ORM 'divide' is coming from. ORMs are powerful, because they let you say less and do more. For 90% of the queries out there, an ORM is fine. SQL is powerful, because you can control and fine-tune your statements. For the remaining 10%, use SQL. Are ORMs bad? No. Can you them for everything? No. The same thing can be said for almost every technology in existence.

lloeki 15y ago
> ORMs are powerful, because they let you say less and do more To me this is a bonus. The real deal is that ORMs allow you to write queries as "first-class" components of the language, hence benefiting from language features such as type checks, duck-typing, factoring, static analysis even, and more. Compare this to stitching strings (however parametrized they are) and manually coercing your object values to strings. This is where, IMHO, ORMs like ActiveRecord and Arel shine, as they give you access to each building block (form connection.execute to .quoted_table_name to .to_sql) so that you can place yourself at whatever level of abstraction between the two worlds you may need.
- nahname 15y ago
  Don't forget the whole other side of it. http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis...
Retric 15y ago
IF ORM's stuck with the 80-90% case I don't think people would have problems with them. Unfortunately, they try to handle an ever wider range of edge cases which tends to create complexity and cruft. As soon as I need to double check their output and I see horrible gobblygook for a moderately complex query I am generally better off writing it myself than trying to understand how I can get the ORM to make a cleaner query. Still, ORM's seem to be getting better Linq to Entity Framework seems to work much better than a lot of the old ORM's I have used.
- debacle 15y ago
  ORMs don't try and handle anything. People apply them poorly which simply creates bad code. The same can be said of the goto statement, or any number of other things - used improperly, they screw up everything, but in some instances they are necessary and good.
  - chris_wot 15y ago
    Actually, that's not really true. An ORM will almost always attempt to convert your object access to SQL. It's not always possible to make it work as well as a rewritten query. For instance, sometimes you need to use an EXISTS, or change a join order with a hint, or find a better way of reducing the driving table's rows to get better performance. With an ORM, no matter how much tweaking you do, it is sometimes impossible to get the performance that a well written SQL query can achieve. And that's not because of bad code, or that the ORM is a bad choice.
    - debacle 15y ago
      BUT...those are problems that an ORM is not a good tool for. If someone is trying to use an ORM for that, that's the programmer's fault, not the tool's.
    - drumdance 15y ago
      IME you can always still write direct SQL when appropriate.
asolove 15y ago
I agree that the 'divide' is overstated. But the author does mention one frequent problem: when you begin a project in an ORM, you may begin to depend on validation or update callbacks that get triggered by the ORM. Later, if you discover queries that need to be written manually, you will first likely forget these rules, then have a hard time translating them into SQL, and then have an enormous, permanent headache keeping the two in sync.
gbog 15y ago
"ORM is fine" 90% or even 100% of the time don't make them right. Thee problem is that OOP is not well defined, it belongs to "soft" science, and relational databases are "hard" science. I have read the article about ORM and Vietnam, in we just have all of the symptoms of impedance mismatch. I have to add that this issue is much deeper than a simple efficiency issue. A perfect db with 100% availability would still not be well matched to an object system. I listened to a podcast from 1990, the guy said "the problem with objects is that we don't know what they are". I just finished SICP, and it seems it is the same conclusion: objects with their state, their messages, their multiple parents, their instanciation, are not a proper model for many or most cases in software development. Example of proper models include types, text files, streams (pipes), modules, maybe services.
- ajross 15y ago
  Related to your point would be an argument that software engineering is more productive when treated as a "hard" science (which I take to mean something like "rigorous justification of all steps" or "clear derivation from principle"). I don't think that's true at all, as evidenced by pretty much every successful software product ever (including the early relational databases, I should add) but would be curious to see the counterargument.
  - gbog 15y ago
    Software is a complex beast with multiple aspects. The UI design can Bree taken seriously but is no hard science. Many interesting parts just can't relate to hard science, even where you have algorithms. But when handling facts data you have the possibility to ground yourself on hard science, and should. It would be a stupid crime to build a tower without grounding what can be on maths and physics, no?
- romaniv 15y ago
  Set theory is hard science. On the other hand, a grapevine of stored procedures with no code reuse beyond copy-paste aren't any kind of science. I'm not even sure they are any kind of engineering.
fusiongyro 15y ago
The divide is fundamentally about choosing what's in charge of your system, the system being composed of your databases, your applications, and your supporting infrastructure (your scripts, your migrations, etc.) To relational database folk such as myself, the central authority is the database, and our principal interests are what ACID exists to provide: concurrent, isolated, atomic transactions that cannot be lost, on top of a well-defined schema with strong data validity guarantees. To us, what's most important is the data, so everything else must serve that end: the data must always be valid and meaningful and flexible to query. The side that argues for ORM has chosen the application, the codebase, to be in charge. The central authority is the code because all the data must ultimately enter or exit through the code, and the code has more flexible abstractions and better reuse characteristics. The reason for the disagreement comes down to disagreement about what a database is about. To the OO programmer, strong validation is part of the behavior of the objects in a system: the objects are data and behavior, so they should know what makes them valid. So the OO perspective is that the objects are reality and the database is just the persistence mechanism. It doesn't matter much to the programmer how the data is stored, it's that the data is stored, and it just happens that nowadays we use relational databases. This is the perspective that sees SQL is this annoying middle layer between the storage and the objects. To the relational database person, the database is what is real, and the objects are mostly irrelevant. We want the database to enforce validity because there will always wind up being tools outside the OO library that need to access the database and we don't want those tools to screw up the data. To us, screwing up the data is far worse than making development a little less convenient. We see SQL not as primarily a transport between the reality of the code and some kind of storage mechanism, but rather as a general purpose data restructuring tool. Most any page on most websites can be generated with just a small handful of queries if you know how to write them to properly filter, summarize and restructure the data. We see SQL as a tremendously powerful tool for everyday tasks, not as a burdensome way of inserting and retrieving records, and not as some kind of vehicle for performance optimization. At the end of the day, we need both perspectives. If the code is tedious and unpleasant to write, it won't be written correctly. The code must be written--the database is not the appropriate thing to be running a web server and servicing clients directly. OOP is still the dominant programming methodology, and for good reasons, but encapsulation stands at odds with proper database design. But people who ignore data validity are eventually bitten by consistency problems. OODBs have failed to take off for a variety of reasons, but one that can't be easily discounted is that they are almost always tied to one or two languages, which makes it very hard to do the kind of scripting and reporting that invariably crop up with long-lived data. What starts out as application-specific data almost invariably becomes central to the organization with many clients written in many different languages and frameworks. We're sort of destined to hate ORM, because the people who love databases aren't going to love ORM no matter what, and people who hate databases will resent how much effort they require to use properly.
dirtyaura 15y ago
I'm running a sales reporting and payroll software written in Django, and it's more like 10% of views benefit from ORM and for 90% views ORM is hindrance and a serious performance hit. I see ORM vs relational style as a development mindset issue. We have moved using SQLAlchemy Core (not the ORM part) and the difference in development style is stunning: now it's quite easy and more importantly FUN to write performant queries, whereas when we were using Django ORM, it was very easy to write non-performant code and tedious to make it fast.
- deleted 15y ago
  [deleted]
- debacle 15y ago
  Yes, I could see that - writing reports is one example of an instance where ORMs are almost entirely useless.
  - dirtyaura 15y ago
    One could pose a question that if you are not doing aggregation, why have SQL/relational database at all. I know, there are several valid reasons to use SQL databases as key-value storages: they are likely more robust than NoSQL dbs, there are API wrappers for most of languages, etc. But for many interesting problem domains reporting and data aggregation is raison d'être for software and that's why I would like to see more solutions in the spirit of SQLAlchemy Core that make it easier to restructure complex queries as a reusable pieces of code, but do not force to you to step into the world of ORMs.

by debacle 15y ago

lloeki 15y ago

> ORMs are powerful, because they let you say less and do more To me this is a bonus. The real deal is that ORMs allow you to write queries as "first-class" components of the language, hence benefiting from language features such as type checks, duck-typing, factoring, static analysis even, and more. Compare this to stitching strings (however parametrized they are) and manually coercing your object values to strings. This is where, IMHO, ORMs like ActiveRecord and Arel shine, as they give you access to each building block (form connection.execute to .quoted_table_name to .to_sql) so that you can place yourself at whatever level of abstraction between the two worlds you may need.

nahname 15y ago
Don't forget the whole other side of it. http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis...

Retric 15y ago

IF ORM's stuck with the 80-90% case I don't think people would have problems with them. Unfortunately, they try to handle an ever wider range of edge cases which tends to create complexity and cruft. As soon as I need to double check their output and I see horrible gobblygook for a moderately complex query I am generally better off writing it myself than trying to understand how I can get the ORM to make a cleaner query. Still, ORM's seem to be getting better Linq to Entity Framework seems to work much better than a lot of the old ORM's I have used.

debacle 15y ago
ORMs don't try and handle anything. People apply them poorly which simply creates bad code. The same can be said of the goto statement, or any number of other things - used improperly, they screw up everything, but in some instances they are necessary and good.
- chris_wot 15y ago
  Actually, that's not really true. An ORM will almost always attempt to convert your object access to SQL. It's not always possible to make it work as well as a rewritten query. For instance, sometimes you need to use an EXISTS, or change a join order with a hint, or find a better way of reducing the driving table's rows to get better performance. With an ORM, no matter how much tweaking you do, it is sometimes impossible to get the performance that a well written SQL query can achieve. And that's not because of bad code, or that the ORM is a bad choice.
  - debacle 15y ago
    BUT...those are problems that an ORM is not a good tool for. If someone is trying to use an ORM for that, that's the programmer's fault, not the tool's.
  - drumdance 15y ago
    IME you can always still write direct SQL when appropriate.

asolove 15y ago

I agree that the 'divide' is overstated. But the author does mention one frequent problem: when you begin a project in an ORM, you may begin to depend on validation or update callbacks that get triggered by the ORM. Later, if you discover queries that need to be written manually, you will first likely forget these rules, then have a hard time translating them into SQL, and then have an enormous, permanent headache keeping the two in sync.

gbog 15y ago

"ORM is fine" 90% or even 100% of the time don't make them right. Thee problem is that OOP is not well defined, it belongs to "soft" science, and relational databases are "hard" science. I have read the article about ORM and Vietnam, in we just have all of the symptoms of impedance mismatch. I have to add that this issue is much deeper than a simple efficiency issue. A perfect db with 100% availability would still not be well matched to an object system. I listened to a podcast from 1990, the guy said "the problem with objects is that we don't know what they are". I just finished SICP, and it seems it is the same conclusion: objects with their state, their messages, their multiple parents, their instanciation, are not a proper model for many or most cases in software development. Example of proper models include types, text files, streams (pipes), modules, maybe services.

ajross 15y ago
Related to your point would be an argument that software engineering is more productive when treated as a "hard" science (which I take to mean something like "rigorous justification of all steps" or "clear derivation from principle"). I don't think that's true at all, as evidenced by pretty much every successful software product ever (including the early relational databases, I should add) but would be curious to see the counterargument.
- gbog 15y ago
  Software is a complex beast with multiple aspects. The UI design can Bree taken seriously but is no hard science. Many interesting parts just can't relate to hard science, even where you have algorithms. But when handling facts data you have the possibility to ground yourself on hard science, and should. It would be a stupid crime to build a tower without grounding what can be on maths and physics, no?
romaniv 15y ago
Set theory is hard science. On the other hand, a grapevine of stored procedures with no code reuse beyond copy-paste aren't any kind of science. I'm not even sure they are any kind of engineering.

fusiongyro 15y ago

The divide is fundamentally about choosing what's in charge of your system, the system being composed of your databases, your applications, and your supporting infrastructure (your scripts, your migrations, etc.) To relational database folk such as myself, the central authority is the database, and our principal interests are what ACID exists to provide: concurrent, isolated, atomic transactions that cannot be lost, on top of a well-defined schema with strong data validity guarantees. To us, what's most important is the data, so everything else must serve that end: the data must always be valid and meaningful and flexible to query. The side that argues for ORM has chosen the application, the codebase, to be in charge. The central authority is the code because all the data must ultimately enter or exit through the code, and the code has more flexible abstractions and better reuse characteristics. The reason for the disagreement comes down to disagreement about what a database is about. To the OO programmer, strong validation is part of the behavior of the objects in a system: the objects are data and behavior, so they should know what makes them valid. So the OO perspective is that the objects are reality and the database is just the persistence mechanism. It doesn't matter much to the programmer how the data is stored, it's that the data is stored, and it just happens that nowadays we use relational databases. This is the perspective that sees SQL is this annoying middle layer between the storage and the objects. To the relational database person, the database is what is real, and the objects are mostly irrelevant. We want the database to enforce validity because there will always wind up being tools outside the OO library that need to access the database and we don't want those tools to screw up the data. To us, screwing up the data is far worse than making development a little less convenient. We see SQL not as primarily a transport between the reality of the code and some kind of storage mechanism, but rather as a general purpose data restructuring tool. Most any page on most websites can be generated with just a small handful of queries if you know how to write them to properly filter, summarize and restructure the data. We see SQL as a tremendously powerful tool for everyday tasks, not as a burdensome way of inserting and retrieving records, and not as some kind of vehicle for performance optimization. At the end of the day, we need both perspectives. If the code is tedious and unpleasant to write, it won't be written correctly. The code must be written--the database is not the appropriate thing to be running a web server and servicing clients directly. OOP is still the dominant programming methodology, and for good reasons, but encapsulation stands at odds with proper database design. But people who ignore data validity are eventually bitten by consistency problems. OODBs have failed to take off for a variety of reasons, but one that can't be easily discounted is that they are almost always tied to one or two languages, which makes it very hard to do the kind of scripting and reporting that invariably crop up with long-lived data. What starts out as application-specific data almost invariably becomes central to the organization with many clients written in many different languages and frameworks. We're sort of destined to hate ORM, because the people who love databases aren't going to love ORM no matter what, and people who hate databases will resent how much effort they require to use properly.

dirtyaura 15y ago

I'm running a sales reporting and payroll software written in Django, and it's more like 10% of views benefit from ORM and for 90% views ORM is hindrance and a serious performance hit. I see ORM vs relational style as a development mindset issue. We have moved using SQLAlchemy Core (not the ORM part) and the difference in development style is stunning: now it's quite easy and more importantly FUN to write performant queries, whereas when we were using Django ORM, it was very easy to write non-performant code and tedious to make it fast.

deleted 15y ago
[deleted]
debacle 15y ago
Yes, I could see that - writing reports is one example of an instance where ORMs are almost entirely useless.
- dirtyaura 15y ago
  One could pose a question that if you are not doing aggregation, why have SQL/relational database at all. I know, there are several valid reasons to use SQL databases as key-value storages: they are likely more robust than NoSQL dbs, there are API wrappers for most of languages, etc. But for many interesting problem domains reporting and data aggregation is raison d'être for software and that's why I would like to see more solutions in the spirit of SQLAlchemy Core that make it easier to restructure complex queries as a reusable pieces of code, but do not force to you to step into the world of ORMs.