As a web developer who has done mostly Rails for a long time, I default to ORMs. And it seems to me that the last 20 years of architecture theory boils down to "How do I put a layer in front of my database?" Once your schema becomes a public API, your app is frozen.
But on the other hand, I believe in using all the features your database has to offer. I remember doing J2EE in the early oughts everyone spoke about being able to swap out one RDBMS for another, and I eventually decided that kind of lowest-common-denominator approach was not worth the cost in preset-day productivity. Plus building on an open source project is less risky than something with outrageous licensing fees, so why not use it? So my own Rails projects have real foreign keys, CHECK constraints, some SQL functions (even some in C), views, and big queries. If I can express an invariant I trust Postgres more than myself to enforce it. I've also had some projects lately where building a JSON response for the front-end involved hundreds of ActiveRecord objects, and dodging that by using the JSON-construction functions in pg 9.4+ is a huge performance win. You can even still use the ActiveRecord DSL to build the query, using your scopes and associations and Ruby code, but then do a `to_sql` and wrap the whole thing in Postgres JSON fuctions. I feel like there could almost be a gem for that. Anyway, sorry for rambling. :-) I agree that Andl could make it much more appealing for people to "put the logic in the database," and I feel like I have been moving in that direction for a long time. Maybe we will see an ActiveRecord Andl adapter?!
> I remember doing J2EE in the early oughts everyone spoke about being able to swap out one RDBMS for another, and I eventually decided that kind of lowest-common-denominator approach was not worth the cost in preset-day productivity.
Remember who was putting the money behind those ideas.
IBM, for example had a vested interest in folks swapping out Oracle for another database... DB2 for Mainframe for DB2 UDB for AIX/x86. Enterprise is a zero sum game, and zeroing out the competition is a way to grow the business.
No ORM ever hits a universally happy solution; graphs and sets are equally powerful but express the world in fundamentally different ways. ActiveRecord is particularly annoying because it is bad both to the database and the programmer.
To the database it is bad by making a great show of holding its nose while dealing with the lowly bit box, making scrupulously sure to avoid taking advantage of the fact that the database has locality and enforceability. I've encountered true production race conditions that Rails validations can't solve. It is a professional embarrassment when clients receive duplicate emails about the multi-umptillion dollar software we've sold them. Meanwhile, a single constraint in Postgres prevents it from ever happening again.
And it's bad to the programmer by exposing a massive interface that you are meant to inherit from for construction. Ironically it's named after the Active Record pattern which is about making a thin interface with a table, which you can then build your own business-specific domain translation layer. But in Rails that's not really how it works.
I used to think the mismatch could be solved by lurching towards sets[1]. But I don't think it would be a very easy transition and more to the point, I don't have anything strong to back up my argument that a collection of grumpiness about the ways various ORMs obscure the power of relational modelling.
From what I've seen of it, LINQ to SQL (or other ORMs hooking up to LINQ on the .NET ecosystem, like Entity Framework) can avoid the feel of what Jacques is talking about. LINQ lets you express queries in C# (or what have you) syntax but still exposes the "feel" of an SQL database, not just using the database as a persistent object store.
As a web developer who has done mostly Rails for a long time, I default to ORMs. And it seems to me that the last 20 years of architecture theory boils down to "How do I put a layer in front of my database?" Once your schema becomes a public API, your app is frozen.
But on the other hand, I believe in using all the features your database has to offer. I remember doing J2EE in the early oughts everyone spoke about being able to swap out one RDBMS for another, and I eventually decided that kind of lowest-common-denominator approach was not worth the cost in preset-day productivity. Plus building on an open source project is less risky than something with outrageous licensing fees, so why not use it? So my own Rails projects have real foreign keys, CHECK constraints, some SQL functions (even some in C), views, and big queries. If I can express an invariant I trust Postgres more than myself to enforce it. I've also had some projects lately where building a JSON response for the front-end involved hundreds of ActiveRecord objects, and dodging that by using the JSON-construction functions in pg 9.4+ is a huge performance win. You can even still use the ActiveRecord DSL to build the query, using your scopes and associations and Ruby code, but then do a `to_sql` and wrap the whole thing in Postgres JSON fuctions. I feel like there could almost be a gem for that. Anyway, sorry for rambling. :-) I agree that Andl could make it much more appealing for people to "put the logic in the database," and I feel like I have been moving in that direction for a long time. Maybe we will see an ActiveRecord Andl adapter?!