10 ms·
(Some) ORM haters do get it
- ianterrell 14y agoThe author's claim that ORMs are bad computer science is probably accurate. Fortunately, they're really good engineering.
- Roboprog 14y agoWe could be more subtle, and go with "it depends". For getting and putting data to be used on an edit form, using an object/class which actually has (non relational constraint) "business logic" in it, ORM good. For batch mass update, ORM bad. (one wonders if every table needs a custom class, though)
- richardlblair 14y agoBatch updates aren't where it ends. As a Django developer with a strong SQL background I find my hands are tied far more often than I would like. Sometimes this is caused by bugs like the current group by bug[1], other times it's caused by the design of the ORM. I do agree that the ORM is handy for things like "Get me all the things in this table", and "update this single record using a form", but this author is dead on. There is logical reason behind the hate developers have for ORMs. [1] https://code.djangoproject.com/ticket/17144 https://code.djangoproject.com/ticket/17144
- gouranga 14y agoDjango's ORM is a piece of junk compared to a proper one such as SQLalchemy, hibernate or nhibernate. I wouldn't go drawing conclusions until you've experienced something else.
- soc88 14y agoIf Hibernate is one of the "proper" ones, then I can happily declare ORMs to be a non-working, time-wasting, over-complicated POS.
- chris_wot 14y agoYour post is of limited value. What, in particular, are the issues that you have with Hibernate?
- chris_wot 14y agoWhat in particular is it about my question that caused it to be voted down? I'm actually very interested in hearing the issues that the responder is having with Hibernate. Unfortunately, because they haven't stated what it is that caused them so many problems, it's of very limited value to the discussion being had.
- gouranga 14y agoI voted you back up. I'm slightly concerned that the down vote was simply retaliatory against the norm which appears to be Common here. I too would like to understand.
- raverbashing 14y agoI unfortunately have to agree wholeheartedly Sure, if you're doing a simple CMS, a simple system (even with Django Auth), Django ORM is fine If you have anything slightly complex (several relationships between models) watch it fall apart
- mb22 14y agoI don't know about the django ORM, however for some other modern ORM's batch operations and statement reordering are one of the top ORM benefits. If you are developing a set of API's that you have no idea how they'll be consumed, the combination of declarative transactions and heuristically optimized ORM based reordered statements + batch updates gives you easy to understand code, proper transaction semantics and really good performance. Without the ORM + declarative transactions you may end up writing ugly apis that pass transactions or connections around and you'll end up having a major task of optimizing the database interactions. Learn your tool, use it for the right use cases and you'll be happy. Putting your left shoe on the right foot will always feel wrong.
- mistermann 14y agoCan anyone point out the coup de grâce the author seems to think he has arrived at? He points out some (well known) ways that ORM's can be used inneficiently, and acknowledges the techniques that have been developed to work around these, but then seems to conclude that he has proven once and for all that ORM's are bad. I totally missed the connection on that part. Is it that SQL is better in dealing with sets than an ORM (a fact no one denies), therefore you should not use an ORM?
- sgift 14y agoThe connection (according to the author as far as I've understood him) is: "All the techniques that have been developed to work around the inefficiencies of ORMs are just reinventing the wheel. The solutions have been there for 40 years and your workarounds are only needed because you think about individuals (object-orientied) instead of sets (relational)."
- stcredzero 14y agoyour workarounds are only needed because you think about individuals (object-orientied) instead of sets (relational). What if it's better structurally for the program as a whole to think about individuals?
- knieveltech 14y agoThat seems to be the question at the heart of the debate surrounding ORM's and OO in general and the debate rages on...
- stcredzero 14y ago80/20 the ORM/SQL.
- mistermann 14y ago> The solutions have been there for 40 years and your workarounds are only needed because you think about individuals (object-orientied) instead of sets (relational) (This is to OP rather than you) Well if that's the argument he's making, one example I can think of, in the case of an extremely complex update, while it always can be done in pure SQL, it is much easier to logically code using an ORM, perhaps even using individuals rather than sets (the horror). And while this implementation might execute slower (.1 second vs .01 second), it is vastly simpler to read and refactor without screwing something up (ie: economically cheaper), and as for the performance argument, it only needs to be fast enough.
- dcminter 14y agoThere is a need to manipulate relational data from object oriented code. ORMs are tools that facilitate that. The Object/Relational impedance problem doesn't go away if you hand-carve the code, it just makes you work hard on all the points of contact instead of just the problematic ones. The real "problem" with ORM is when people use such tools as a way of avoiding having to understand databases (and specifically SQL). Fortunately that's becoming less common at least within the Enterprise Java world where I live and breath.
- mb_72 14y agoI think you've hit on something here. I came to start using ORMs after 10+ years of writing / optimising databases and SQL. When using an ORM (and most of my work is done with a probably not-well-known one, XPO from DevExpress) I'm aware of what is (or should!) be happening under the hood; my prior experience with 'bare metal' is extremely useful, nay essential to creating a performant system. On occasion, it's necessary to do a direct SQL query, but not often. Sure, the apps I'm writing are for small-medium business, but XPO 'just works'. Context is important; if I was working on something with more users / tighter speed requirements, an ORM may or may not be the best choice. Still, this falls into the 'right tool for the job' category that good developers are already aware of.
- FuzzyDunlop 14y agoI'm well open to correction on this, since I've not much of a clue, but with all this ORM back-and-forth, and relational databases, why do we not see more usage of graph databases?[1] From the wiki, it says they map more directly to OO applications. Is there a reason relational databases are still used by default? [1] http://en.wikipedia.org/wiki/Graph_database http://en.wikipedia.org/wiki/Graph_database
- nknight 14y agoInertia, accidents of history. Relational databases had obviously-useful properties at critical points in the history of mass commercial adoption of computing. As a practical, real-world matter, "object-oriented programming" barely existed during the rise of relational in the 70s, making the practical problems caused by the impedance mismatch either non-obvious or seemingly unimportant. As a result, huge investments were made in advancing relational databases, and other forms have languished. Today, relational maintains the substantial advantages of maturity and installed base. Performance, reliability, general polish, ease of access to support/tutorials/other literature, and general status as "the way things are done".
- biafra 14y agoSometimes the reason is that operations is used to it.
- ExpiredLink 14y agoThis article is very much to the point. ORMs use the wrong abstractions. They try to 'map' 4GL to 3GL. The results are necessarily unsatisfactory.
- soc88 14y agoAbsolutely right!
- debacle 14y agoI 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 14y 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 14y agoDon'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 14y agoIF 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.
- 14y ago
- euroclydon 14y agoWell now I'm reminded of my initial though when a colleague first introduced me to an ORM: "It feels wrong to use this tool to just map every object to a table." Of course I went on to write many, at best, moderately complicated web apps very fast using NHibernate and didn't miss writing vender-specific SQL or column to property mapping boilerplate. But this article is a breath of fresh air. I may just try Dapper for the next project http://code.google.com/p/dapper-dot-net/ http://code.google.com/p/dapper-dot-net/
- koide 14y agoI agree, microORMs are the right solution if you are trapped in the mainstream. I'm a very happy user of Dapper.
- bitdiffusion 14y agoI think the other point the author makes is that it's not possible to write efficient code that is entirely abstracted from the underlying data (see his loop examples). i.e. if you have to write your code in a specific way to make the ORM behave correctly (constantly thinking about what kind of sql your code is generating), then the abstraction becomes a lot less useful.
- scotty79 14y agoFor easiest things SQL is cumbersome. Getting single row by primary key which is 90% of access is overly verbose in SQL so ORM wins. For slightly more complicated cases SQL is much faster and easy to write so people who have to increment field in all rows that satisfy simple condition go: "ORM sucks". But for more complicated cases like trimming data tree in some places SQL quickly becomes too much of a puzzle for most programmers to deal with so they prefer ORM again because it's doable there and most of the times works. Dedicated SQL users who are not good at puzzles in such cases write full fledged program (if their SQL dialect allows for that) and instead of bringing data to their iterative or recursive programs they bring their programs to the data which creates hard to debug, unreadable often unversionable monstrosities. There should be some merge between databases and programming languages that could combine beauty of syntax of modern programming languages and efficiency of massive data handling of modern databases. Why is it ok to have standard hashmap implementation in a language but not file backed hashmap or btree index?
- mckoss 14y agoI think this is the motivation behind .Net Linq - bringing the relational query semantics into the language. http://msdn.microsoft.com/en-us/library/bb308959.aspx http://msdn.microsoft.com/en-us/library/bb308959.aspx
- bkirkbri 14y agoI'm pretty sure that this is the motivation behind http://datomic.com http://datomic.com
- soc88 14y agoThe idea of translating the declarative way of doing things to an imperative approach (that's basically what ORMs are doing) is imho a huge failure. It just never worked decently. These days, we have languages which integrate rather nicely into the declarative mindset, so no need anymore for such bizarre "paradigm translators".
- koide 14y agoWhat are those languages and how do they integrate nicely into the declarative mindset?
- superasn 14y agoI think the problem with ORM is that at the end it is only a wrapper over SQL, say like Winzip is for Zip. So while it may look pretty and easy to use, it always has to obey the rules of the host program, and so workarounds such as these have to be invented. On the other hand if somehow ORM was part of the core compiler AND database, then somehow it could be possible that even when you write a for loop on the top and have an if conditions inside the block, or perform a join, the compiler understands it and pre-compiles your code without needing such workarounds (as there aren't two separate layers to join). So you would treat objects and objects and never have to worry about how the wrapper is being generated or what kind of indexes or queries it will run finally. I'm not an expert at compilers though but for strictly typed languages it could be possible.
- pbz 14y agoThat would never work though, at least not in the perfect, non leaky way the author and you would like. When you have a loop, even if the database could somehow understand that loop, you can put anything inside it. You could make a call to an outside service, write to disk, etc. With a single SQL query the database can take it and optimize it since it has a full understanding of its data domain.
- kstrauser 14y agoHe's wrong. SQL is great for what it does, but I use ORMs for reasons other than writing queries in a different way. I inherited an utter mess of a schema that wasn't even remotely close to 1NF. Imagine fields containing comma-joined sets of values, and with column names not even remotely related to what they actually held. For legacy and business purposes, updating the schema was a non-starter. So I used SQLAlchemy to remap the schema into something usable. I wrote getters that split out those comma-joined fields and returned the desired value against tables that required indexes like: UPPER(SUBSTR(name_delpt,1,STRPOS(name_delpt,','))) I wrote (and therefore more importantly _documented_) the bizarre and complex way some of the tables joined together. I wrote something that was unit-testable and that could be used as a foundation for other work so that I wouldn't have to memorize the insane corner cases and reproduce them from scratch each time I needed to access the data in some little-used table. I _didn't_ write a more convenient way to say `SELECT * FROM blog`. In general, that doesn't interest me and I wouldn't have bothered with it. ORMs are great - if used well! - for encapsulating all of the little bits of business cruft in one central, easy-to-manage place. They're handy for roughly the same reasons that subroutines are handy.
- thespons 14y agoThis is an interesting use and I like the idea, but I don't think it makes him wrong. You don't actually need an ORM to do this. The same logic could be applied to data sets retrieved through regular queries. Or you could create views/stored procedures with the same logic.
- SoftwareMaven 14y agoYet another software religious war, which seems to boil down to "if you don't think my technology is correct 100% of the time, you are insulting my honor". Do other fields get into constant pissing matches like this? Languages, libraries, process, licenses, editors, Operating systems, you name it, software engineers are fighting about how much better theirs is and how you are an idiot for not seeing the true light their vast intelligence is trying to bequeath unto you. What is it about our brains that makes the subtlety of "use the right tool; every problem isn't a nail" so difficult? Or is it just hard wired into our need to be identified with a community?
- pbz 14y agoIt's probably directly proportional to one's OCD level or amount of pain accumulated through the years. There's also the need to show and feel that you're superior, and sometimes the need to point out that somebody's superiority is irrelevant.
- parfe 14y agoAny system I've worked in that didn't use an ORM still implements an ORM. Save methods which runs insert or updates. GetAll methods get_by_username, get_by_id, get_by_email, get_recent, get_by_foreign_keyed_object, get_by_other_foreign_keyed_object. And all those hand coded methods directly tied to the dialect of the db the original developer used. Using Hibernate I had to write raw SQL for some reporting. I've never written raw SQL in Django (the project I've used django on self select for simplicity). And using SqlAlchemy/Twisted as a backend for a desktop application I haven't found a need yet, for performance or correctness. I have one query I'm eyeing for an SQL rewrite, but it'll probably be a week of work to make sure it works correctly and I'd rather release this phase than save 30 seconds on a weekly query. I've reached a point where ORM complaints don't really make all that much sense. The issue seems to be "THe ORM breaks down doing X and Y and Z so I had to hand write SQL!" But you'd be writing X Y and Z anyway if you weren't using an ORM, so what's the issue?
- mistermann 14y agoExactly. Or more explicitly, the anti-ORM argument, to me, consists of: ORM works fine for A through W, but SQL is better for X, Y, Z. So rather than just the common sense solution of writing just X,Y,Z in raw SQL, everything has to be written in raw SQL.
- wvenable 14y agoThe argument works both ways; in fact, I think it's worse the other direction. Most projects use the ORM and just the ORM and it's against policy to write anything in raw SQL even if it's better for X, Y, Z.
- mistermann 14y agoI'm sorry but I don't think you're telling the truth. I've never encountered in real life, or during any online discussion, the all-or-nothing sentiment from advocates of ORM. Could you link to anything online where an ORM advocate argues that you should never drop down to raw SQL?
- chris_wot 14y agoI agree with a lot of what you he says, however what about the case of getting 10 rows with 20 columns - each column needing a join. The optimizers often go nuts over this sort of thing, as that's 20! combinations the optimizer must iterate over to get a good join order. Apparently, Postgres has a genetic optimizer that handles this... curious to see if this is an issue or not. Incidentally, I'd like to say that I loved the author's Relational Basics II at http://www.revision-zero.org/relational-basics-2 http://www.revision-zero.org/relational-basics-2 I've come to the conclusion that SQL is particularly limited in its application and implementation. I'd love to see a better declarative language for databases!
- nsxwolf 14y agoThis article is all about RBAR vs. set based operations. It has little to do with ORMs per se. That naive ORM users may tend toward RBAR is beside the point. Go RBAR when it doesn't matter - when it's convenient and you know how it is going to scale ahead of time. A user updating his profile. Creating an order. Go set based the rest of the time - when you're processing a large batch of data for thousands of user accounts, offload that work into a stored procedure and call it. ORM does exactly what it is meant to do, and if you're working with data in an OO model, you're going to be doing ORM, whether you know it or not - you will either pull a decent ORM tool off the shelf, or you WILL be writing your own very bad one.
- recursive 14y agoWhat is RBAR?
- nsxwolf 14y agoRow-By-Agonizing-Row, or iterating over a list of rows and operating on each individually with a new query. Your average Java programmer is used to iterating over collections in a while loop, where 30,000 in-memory objects can be quickly modified. It's tempting for said programmer to do the same to ORM-backed objects and issue 30,000 sql update statements across the wire.
- jakejake 14y agoAs an author of an ORM I can agree with the OP that using them incorrectly can lead to horrible punishment on the database. He seems to be most concerned with the n+1 issue which happens when you loop through objects and another query is performed on each iteration. If you're going to use an ORM then you absolutely have to learn the mechanics to avoid n+1 queries. Every ORM is a little different, some are easier to tune than others. I personally favor a basic mapping that the ORM does automatically combined with an advanced mapping that allows you to basically write queries for special purposes and map them to transient objects that don't necessarily exist in your schema. You have to do this for things like aggregate queries or calls that require several joins but only need a couple of columns from each table. The OP raises some good points but I do think that ORMs can be used properly to great effect.
- Ixiaus 14y agoI hated every single ORM "system" I have ever come in contact with from many different languages with the exception of one: SQLAlchemy. SQLAlchemy isn't just easy and intuitive, it is really smart and well built. For a long time I was on the side of the ORM haters, until I tried SQLAlchemy - it truly is an awesome ORM package and I have yet to find anything like it in PHP/Ruby/etc...
- iainduncan 14y agoAs is so often the case, IMHO the poster is ignoring the business side of the equation in favour of "correct". A good ORM is fantastic for speeding up development. If you design your db around being well usable with the ORM, the potential development gains (at least in dynamic languages like Python) are HUGE. I left Django in part because of their ORM. But using SQLAlchemy, we develop far, far, faster than if we were using SQL directly. And it's flexible enough to allow me to drop into the SQLAlchemy Query language when I need to hand tune a query, or to SQL itself if I really need to get close to the metal. Will there be downsides one day? Probably. Will they come even close to the business value of the amount of the coding time we've saved during the critical bootstrap phase? No way in hell. As they say, those are problems I'd love to have.
- skybrian 14y agoThis is all very nice, except that users often do want to work on individual records (at least when updating them). Codd's simplifying assumption is for mathematicians, not users.
- ScottBurson 14y agoThere's a problem that's inherent to any client/server architecture: what work should get done on the client, and what should get done on the server? The author presents this as an ORM issue, but it has nothing specifically to do with ORMs; you'd have the same problem using an OODB server.