The 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)."
> 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.
The problem is, in the real world the performance divide between iterative and set-based solutions often spans much more than just one order of magnitude. For someone who's got solid experience in constructing set-based queries, the SQL solution can quite often be simpler to read and refactor as well. That's admittedly a big 'for', though. Good database folks reason about this stuff in fundamentally different ways, and there's a lot more to creating a good database person than simply teaching a programmer SQL.
In respects like that, ORM's greatest benefit is also its greatest downfall. Using an ORM means you can put people who don't have a strong grasp of databases in charge of your databases. Sadly, it also means that you've put people who don't have a strong grasp of databases in charge of your databases.
For that matter, only needing to be "fast enough" is fine if you're the only kid in the playground. That's often a safe assumption to make if you're writing app code, but less so with databases. If the database is being shared by a number of applications, or if the server is hosting multiple databases, or if you have to worry about concurrency, then being "fast enough" probably isn't enough. Because you've also got to think about all the other ways that your queries could be affecting everyone else, and making sure you aren't subjecting your server to the tragedy of the commons.
Which comes to another nice thing about having a dedicated database person. It means there's someone whose official bailiwick is the DBMS. If app A isn't experiencing any performance problems itself, but is causing performance problems for app B (say, because of some perverse locking situation), that's a bug that a DB guy is best positioned to diagnose and fix. If the application isn't too tightly coupled to the database (i.e., sprocs are in place) then he can even quietly fix it on the server side without having to hassle anyone about the application code. A team that's too ORM-reliant, on the other hand, risks failing to include anybody who's even well-equipped to recognize the problem, let alone fix it.
Which is creating a false dichotomy. Assuming your are using some OO language then you will have to, at some point, turn the relational data into objects. At that point you are always creating an ORM.
> Assuming your are using some OO language then you will have to, at some point, turn the relational data into objects. At that point you are always creating an ORM.
This is not true.
At some point, you will need to extract a subset of the relational data and represent it using your application's in-memory model. If your hand is not forced by the ORM, this is unlikely to be a direct mapping of the database.
This is no different than a network protocol, wherein the protocol is not a direct representation of application state, and the application does not attempt to model the network protocol using the same constructs that it uses to model its in-memory state.
I don't see how ORM forces your hand to be a direct mapping of the database. To me the benefit of ORM is that, most of the time I do want a direct mapping of the database, but there are often times when I need to add a layer of abstraction/validation/redirection on top of it.
The direct mapping of the database that it provides isn't really direct, and the impedance mismatch makes a mess of what could be a simple, easy to understand in-memory application model.
No, you haven't. If your in-memory application model mirrors your database model, you're probably doing it wrong; either your application model is poor, or your database model is.
