5 ms·
It's hard to explain to developers why an ORM isn't really that great of a solution....but at a high level: * your database is the core of your app. Abstractio
by manv1 4y ago
It's hard to explain to developers why an ORM isn't really that great of a solution....but at a high level:
* your database is the core of your app. Abstraction implies that you don't care about the details of your data store, which eventually will lead to two major problems:
1. When things are slow you won't be able to debug it, because you're abstracted away your database and don't understand what queries your ORM is using to do things, and
2. when your ORM migration fails you won't know what to do, because you don't understand your database. In general this happens with every ORM product, ever, because you didn't put in a constraint initially because you didn't know what that meant and then you did later, which caused the migration to fail because your constraint is being violated. Or the migration fails because the tool uses some attribute and not others for drift detection, so it tries to delete your table/database because it's detected drift.
* the way you deal with data in code and in a database are different. Code iterates over objects. If you just use your ORM naively you'll end up doing some ridiculous number of selects because in code it looks like you're just iterating over objects...when in reality the ORM is doing a select/join for each one of those objects. And if you start getting more complicated there are structures that are just harder to do with ORMs...because you have to map what you're trying to do in SQL to the way your ORM works. At that point why not ditch your ORM?
SQL isn't really that hard...but thinking about how do queries is harder than you would expect. It's almost an order of magnitude faster to do joins in the database than to join stuff in-code...but that also assumes that your schema isn't screwed up, it has indexes, etc.
Lastly, a lot of ORMs don't put indexes on columns for some reason, which kills performance. You'd think that would be a detail that would be abstracted away for you at the ORM level, but it isn't. I mean it knows what you're using to select data, so it should auto-create indexes for you, right?
- selcuka 4y ago> I mean it knows what you're using to select data, so it should auto-create indexes for you, right? Curious, how does it know what you're using to select data?
- manv1 4y agoBecause you're using the ORM to do selects. I'll give you an example: prisma has a "find/findMany." As part of the build process it should examine your usage and put indexes in the column that you're using in find/findMany Indexes are an implementation detail - but to use RDBMSs successfully you need indexes. ORMs try to hide those implementation details, but without those kinds of details you get bad performance. Prisma just fixed another problem it had with transaction isolation levels. To even understand the problem you need to understand SQL, how databases work, and how each database implements that. It's another important implementation detail that's abstracted away...until it bites you in the ass. Prisma also finally allowed you to use database-specific types instead of just using varchar(191), which was its default for strings. I'm picking on prisma because I happen to be using it right now. There are good things about it, like the way it does migrations and handles schema changes. But there are times its abstractions get in the way, like when you're trying to do aggregated group by (which is easier in SQL than it is in prisma). And its migrations often fail, and to understand why you really need to understand SQL. Hibernate was worse, because it provides a transparent object-level backing store.
- selcuka 4y ago> As part of the build process it should examine your usage and put indexes in the column that you're using in find/findMany This is not as easy as it sounds, though. Reliably inspecting source code is hard, and definitely not in the scope of an ORM. It also can't catch dynamically generated queries (think user configurable filters). It might be a good idea for a third party product that analyses your code and suggest adding indexes to models. You know who knows best about your queries? It's the RDBMS. There are tools that can add/suggest indexes by searching your database logs for slow running queries.
- watwut 4y agoAd2: Every single real world java project I have seen used hibernate (ORM) with flyway. I never ever seen any project in production where some underlying tech would be deleting tables autonomously. Ad1: People do debug ORMs, actually. Including queries effectivity.
- manv1 4y agoAd2 -> I've run into lots of hibernate apps. They also tend to use Spring, and the team often gets lost trying to figure out which one is the cause of the problem. It's usually both. Hibernate and Prisma migrations will delete tables if you allow them to. Ad1 -> I'm sure they do...but usually they call in a DBA, who basically says "this is a disaster" then recommends that they refactor everything because their database schema is fucked up because it's based on some weird object hierarchy instead of RDBMS principle.
- watwut 4y agoI dont find neither of your responses consistent with reality. First, database administrators do not debug ORM. Second, it does not take specialist to debug those, developers debug those. Third, recommendation is rarely "refactor everything". Usually it is adding an index, change the query or some other minor tweak. Fourth, "weird object hierarchy instead of RDBMS principle" does not even mean anything. Fifth, spring has nothing to do with database whatsoever. Sixth, every production code I have ever seen used flyway.
- adammarples 4y agoI think you're mixing up someone who's decided to use an ORM rather than some hodgepodge of string concatenation with someone who has no idea what a database is, is unable to set it up effectively, and is unable for some reason to debug the sql emitted by ORM queries or use their ORM at all effectively to avoid N+1 problems. Not really a fair comparison.