241–250 of 354 posts
ORMs are bad - I’ll just use SQL.
Hmm - I need to map these results onto objects I can use.
Hmm - wouldn’t it be great if the object tracked changes and could save itself.
I need related/child objects - wouldn’t it be great if I could auto fetch them. …
Earlier quoted context omitted.
It should be table stakes for any SWEs working on backend, but it's not. The DB and the code directly interacting with it are way more important than anything you're going to write on top. I keep ending up in situations where I'm the only SWE in the room who really knows SQL, let alone proper schema design, and I have to speak up or else they're going to build an abomination.
But for a lot of people, the focus there is in the "write on top" layer, because they enjoy it more (I suspect). Constraints etc are tested there. But this is caused by another shift (I didn't experience this firsthand so bear with me); early databases often had multiple clients, nowadays it's often a 1:1 relationship with one application owning the DB. Which makes putting in constraints in SQL feel clunky. The bigge…
Not much can beat stored procs when it is dealing with multi-step heave volume stuff. But I don't miss not having to do hacks for logging and debugging compared to the flexibility offered by non-db side.
For pretty much everything else, the poor ability to log and debug makes them a headache to manage. I
I don't disagree with any of the major gripes people have with orms and I find SQL to be much cleaner in a lot of circumstances. That being said, if orms didn't force you to explicitly define your domain models about 60% of developers would simply never do it. And you would see differently structured, ad-hoc interfaces defined all over the code base completely entangled with whatever action they are trying to perform…
I'd rather take a mess of ad-hoc interfaces. Forcing people to do domain modeling does not go well.
Why not both? ORMs for the simpler CRUD operations, SQL when it gets a little hectic. The author basically says this in the first paragraph, but the title (and some of the language the author uses) implies that people should just use SQL. It's a reasonable article pointing out some of the annoyances and problems of ORMs (especially in the Java world, where they tend to be overengineered) but there are still a lot of…
You can optimise your schema for the convenience of your application code, or you can optimise it for the truth of your domain model. The former makes glue code easier. The latter gives you stronger constraints, better performance, richer queries, and a database that can answer questions the application code never anticipated.
Earlier quoted context omitted.
The problem with ORMs are 1. They pretend SQL is standardized, and support a heavily reduced featureset for any given database as a result 2. They leave awkward holes in their abstraction, leading to psychotic behaviors like N+1 and implicit type coercions to helpfully break your indexes silently 3. They make simple queries simple, and hard queries absolutely revolting 4. You end up not wanting to use the objects dir…
I have list of issues with SQL. Not composable. Unable to detect query errors at compile time because the schema is only loosely coupled to the code base. And as you yourself point out, SQL is not standardized, which is also terrible and leads to things like Oracle vendor lock in. And frankly this list hasn't changed in 30 or maybe 40 years now. And DBA's were so notoriously egregious that Martin Fowler made his "NoD…
But that is not what ORMs are. They teach bad habits that make SQL harder to understand, not easier, because the power of SQL depends on good data modelling.
Perhaps the worst habit is treating the database as subservient to the application code. This assumption comes naturally to many programmers. In most programming contexts, file formats, wire protocols, and internal representations are defined by the code that consumes them. That's fine in some cases.
But in a data-centric application, the relationship should be reversed. Before writing a single line of application code, you should understand the domain model and design a schema that represents it well. The database is not just a persistence layer for objects. It is the system of record, and its structure should reflect the shape, constraints, and relationships of the real-world data. Everything else should be built to conform to it.
People have been making these same arguments for decades and at this point I'm convinced they are all based on the same strawman: That ORM's absolve you from having to learn SQL. Once you understand that was never actually true to begin with you can treat the ORM as a tool that simply helps you generate repetitive boilerplate queries and hydrates result rows back into objects for you. Furthermore, if your objects are…
The problem with ORMs are 1. They pretend SQL is standardized, and support a heavily reduced featureset for any given database as a result 2. They leave awkward holes in their abstraction, leading to psychotic behaviors like N+1 and implicit type coercions to helpfully break your indexes silently 3. They make simple queries simple, and hard queries absolutely revolting 4. You end up not wanting to use the objects dir…
Best solution: Learn SQL and understand the relational model. Learn data modelling and normalization. Then choose a good ORM which does not get in the way, but saves a bunch of boilerplate code.
An ORM only saves you boilerplate if you’re mapping relationships to objects. And if you’re doing that, you haven’t learned good data modelling and normalisation. ORMs are for storing objects. SQL is for correctly modelled data.
I don't disagree with any of the major gripes people have with orms and I find SQL to be much cleaner in a lot of circumstances. That being said, if orms didn't force you to explicitly define your domain models about 60% of developers would simply never do it. And you would see differently structured, ad-hoc interfaces defined all over the code base completely entangled with whatever action they are trying to perform…
I’m thinking about what Rails would look like without activemodel and activerecord. Or even just without activerecord, where we had to write the same sql every time we wrote a model but introduce the opportunity for a dev to screw it up. Imagine starting on a legacy code base and all the models had subtle differences in how they query the db. They don’t have the established conventions around _id fields, polymorphism, the nice bits around joins, and instead you have to discover bugs where you did a join but the two models each have a field called “description”…
Earlier quoted context omitted.
An ORM only saves you boilerplate if you’re mapping relationships to objects. And if you’re doing that, you haven’t learned good data modelling and normalisation. ORMs are for storing objects. SQL is for correctly modelled data.
There's a middle ground between ORMs and raw SQL, especially if you're using a strongly typed language. My library Zapatos[1] is one example among several. [1] https://jawj.github.io/zapatos/
I think ORMs mostly exist because most programming languages tend to lack an elegant way to write SQL and interact with results. Somewhat ironically, the much-maligned CFML (aka ColdFusion) got this right decades ago. It made SQL string building trivial, and it provided a native data type for tabular query results.
No other language I'm aware of has this, and it's the missing piece in many modern ecosystems. They do not need an ORM. They need better ergonomics for interacting with databases: a clean way to compose queries, execute them, and work with the result as structured relational data rather than shoehorning it into application objects.
Earlier quoted context omitted.
> ORMs are good for management and simple CRUD cases I for one think that "simple CRUD cases" is bullshit, those applications don't exist. In practice, System-of-Records systems are rare. (and should be, their value are inversely proportional of how many of those you have in your overall system). Because if it was "just simple CRUD", one would use the database directly? Databases are already capable of handling CRUD…
No. If you have a simple line-of-business app, writing Django/Rails models is FAR easier than the equivalent SQL. Even if you think that maintaining your domain model is easier in SQL (it’s not, for most full-stack engineers), the extra capabilities you get from an ActiveRecord framework such as full-stack admin pages, free migrations, etc. win overall. I can believe that the gap is closing with the “api for your Pos…
One lesson I've carried for years is that most of the time the client needs denormalised views on the data model. That's the boundary; the server has the clean domain model, and the client works with views on that model. Isn't that exactly what an ORM is for?
I built mine in Dart because I want the server and client to share DTOs. Then I built a visualizer for clientside devs to be able to explore entity relationships (DDD style) and generate a JSON contract. The end result is no REST back and forth, no GraphQL complexity, just everyone in the team focusing on what they're good at.
I think the theme that ORMs are easy to start, but you pay for it with the edge cases, so good devs end up back at SQL does not apply when you're thinking about how to build a platform. Everyone has their strengths and weaknesses. Aligning the team on playing to their strengths was my goal when I reached for yet another ORM as the solution.