5 ms·

Ask HN: Have you found ORMs help more than they hinder?

• fiedzia 8y ago
  1. Good luck finding all places that access some table if you want to change something, especially if table is called users or products. 2. ORM provide abstraction layer. Otherwise every place needs to know all details of tables it accesses. Migration from db to solr for example is much easier with ORM. Ensuring that you call strip_html or other logic in all relevant places is also easier if you have one entry point you can hook into. 3. Strings compose poorly. Building complex queries from set of parameters sucks. 4. Database portability is crucial, even if you will never migrate. It gives you access to far greater mindshare and toolset.
  • ccajas 8y ago
    Is this also a useful tool from an administrative point of view? One of my friends is a db admin and he has not heard of ORMs at all.
    • fiedzia 8y ago
      Probably not. The only point of contact with an admin I can think of is that orms can manage schema migrations.
  • akudha 8y ago
    Good luck finding all places that access some table if you want to change something Is it really that hard though? All we need to do is have a class for Users (or products or whatever) and put all queries in that class. ORMs are annoying, they add another layer of complexity and take the joy out of just writing a simple query. Now I have to learn yet another syntax which is totally unnatural. There is no guarantee these ORMs convert to optimized queries, and not all ORMs support all SQL features either. Just reading a 20 line ORM query with multiple complex joins vs the same thing written in plain SQL hurts the eyes and brain.
    • fiedzia 8y ago
      > All we need to do is have a class for Users (or products or whatever) and put all queries in that class. Yes, and this is very close to doing what orms do.
• amarraja 8y ago
  They are useful if you only use them for simple things. Any queries which are non-trivial or aren't cleanly expressed in your object model can lead to absolutely monstrous queries. I once saw a 1000 line query - which unsurprisingly timed out - generated for getting a single user record from the database! There were several lookups to rate limit failed login attempts etc, however this should be a couple of lines of efficient sql if hand rolled. I can tolerate something like Rails' ActiveRecord if used with restraint. E.g. user.addresses << Address.new(blah) Is very useful, it doesn't get in the way and does all the boring stuff for me. People just need to learn this isn't the only way to access the database, and you can drop to sql if you need to. Fortunately I started developing at a time where there were no ORMs, but I fear there is a new generation of devs who see SQL as some esoteric ASM for databases. Also, I disagree with database portability as an argument for ORMs. All abstractions are leaky, and trying to unify everything will stop you taking full advantage of your data-store of choice
• bjourne 8y ago
  Perhaps you are suffering from Blub? http://wiki.c2.com/?BlubParadox http://wiki.c2.com/?BlubParadox One reason for wanting to shift databases is testing. The unit tests might be running on the developers own sqlite instances because running them on the company-wide SQL Server installation is prohibitive. A well-written ORM generally do not introduce much complexity. For example, C# Linq expressions (yes, I know they are used for many other tasks than db access) aren't more complex than the equivalent sql statements.
  • mmt 8y ago
    > One reason for wanting to shift databases is testing. The unit tests might be running on the developers own sqlite instances because running them on the company-wide SQL Server installation is prohibitive. That doesn't strike me as a shift, though. Presumably, if sqlite (or, say, its heavier weight, also free, cousin PostgreSQL) can mimic enough functionality of the proprietary company-wide db, why isn't bare SQL enough to access those functions? Why is SQL not a good enough abstraction? Too difficult to ensure one is writing a portable subset of the language? > A well-written ORM This runs into the danger of being a "true Scotsman" type argument if it doesn't apply to at least most popular ORMs (or at least one for each popular language). > aren't more complex than the equivalent sql statements. They are, by definition, if one already knows the equivalent SQL statement: one has to learn the additional, separate syntax.
    • bjourne 8y ago
      > That doesn't strike me as a shift, though. Presumably, if sqlite (or, say, its heavier weight, also free, cousin PostgreSQL) can mimic enough functionality of the proprietary company-wide db, why isn't bare SQL enough to access those functions? It is, but then developers have to make a conscious effort to stick with a portable subset of SQL. It is much easier to have an ORM do that job for you. > Too difficult to ensure one is writing a portable subset of the language? For complex applications, that is very difficult, yes. > This runs into the danger of being a "true Scotsman" type argument if it doesn't apply to at least most popular ORMs (or at least one for each popular language). Some of the earlier Java EE ORM:s were truly garbage. They included way to much convenient magic. For example, it was often hard to predict whether a someObj.getFoo() call would trigger a database lookup or not. OP might have cut his teeth on one of those and therefore believe they all introduce extra complexity. > They are, by definition, if one already knows the equivalent SQL statement: one has to learn the additional, separate syntax. For example, in C# Linq is already used for functional list processing. Using them for SQL is just a change of backend.
• superasn 8y ago
  I don't know I personally find them quite useful and time saving, esp Eloquent ORM. I don't think I have written a direct sql query in a very long time unless it's an exceptional case like below. But the best part is if I ever needed to, the ORM isn't stopping me.. like recently I wanted to `insert ignore` thousands of values in the table using a single sql query. Afaik that isn't supported by Eloquent so that I did using query. Rest the ORM is able to handle almost everything and keeps the code much more readable and easier to write.
• mabynogy 8y ago
  Nor me. A possible smart ORM should take the DB as it is and shouldn't generate static code (ok at runtime).
• acesubido 8y ago
  ORM's are nice for majority of writes and simple reads based off of an object (a model). It starts to hinder once there's a requirement for complex reports. I find, that's where the distatse of ORMs in an organization starts. The other way to deal with majority of these complex reports is to create a separate OLAP table (model) to write/update too, and pull aggregates from there. But that's treading on a thin line of over-engineering. ORM's are supposed to be used for Objects. If a report isn't a well-defined object/model, then it's going to fight against an ORM.
• UK-Al05 8y ago
  Micro orms are the sweet spot for me.
• tmaly 8y ago
  ORMs are good for dealing with the domain by representing abstractions in a clear fashion. The assumption is that you usually have highly normalized tables. If you do not have highly normalized tables due to cruft and technical debt, it is usually easier to use plain SQL.
• ed_at_work 8y ago
  An ORM is like any other tool, you can either use it properly or misuse it. I've seen terrible hand written SQL code, and I've seen terrible LINQ queries. But with EF for example, once you learn LINQ and it's power, it becomes a very invaluable tool. Also, the argument of it getting in the way is moot too, as you can still call a stored proc via an ORM as well.
• neilsimp1 8y ago
  There's been more than a few times where I'm working on a smaller project and start looking at ORM's, the time it would take to learn the ins and outs and getting it set up, and then just write a few SQL statements instead and call it done.