5 ms·

For some reason, Java developers didn’t like writing SQL, so we introduced Hibernate which “does SQL for you”. Hibernate creates appallingly bad SQL, so “datab

For some reason, Java developers didn’t like writing SQL, so we introduced Hibernate which “does SQL for you”. Hibernate creates appallingly bad SQL, so “databases are slow”. Particularly when using a getter on a lazy-loaded relationship. A query might end up taking 1ms per record instead of 10ms for 10k records. You can rewrite all you want in Hibernate and greatly improve performance, but you often need to introduce Projections, lazy/nonlazy flags, in the end you program Hibernate more than you would have written basic SQL. Ah, also you’re writing JQL not SQL, so you need to learn “how it’s written in JQL”. But every Java developer is happy, because it’s Java. Phew, at least you didn’t write SQL! - Any storage, even file or memory storage, can perform better on production than Hibernate. - Devspeed is much faster without Hibernate. Source: I’m a founder, initiated a few apps, one is on prod making money after 2 weeks, the other one is still losing money after 18 months, guess which one uses React-Spring-Hibernate and which one used jQuery-Freemarker-Dropwizard. - But if you want competent developers, React-Spring-Hibernate makes you look young and cool. It’s sad, because frameworks are as difficult as the maximum difficulty our developers can handle, and if they’re not, they will add a layer. Conclusion: People have no love for databases because they’ve put too many layers before them. But they are not the problem.

tuatoru 5y ago
What ORMs have taught me: Just Learn SQL https://wozniak.ca/blog/2014/08/03/1/index.html https://wozniak.ca/blog/2014/08/03/1/index.html
- Rapzid 5y ago
  I like how the very first paragraph walks back the title.
gunnarmorling 5y ago
Hibernate isn't at all meant to avoid understanding or writing SQL; rather, it is meant to map result sets of queries to managed object graphs, track mutations to the loaded graphs, and synchronize those changes efficiently back to the database. The SQL generated by Hibernate is as good or bad as you tell it to; something like inappropriate config causing the n+1 SELECT you describe will instantly show up in any decent dev workflow. You're not bound to JPQL, you can very well use SQL directly too if that benefits your situation. As any powerful tool, Hibernate ORM requires good knowledge of it in order to use it efficiently and effectively. Use it if you have the problems which it solves; don't use it, if you don't have those problems. Disclaimer: former Hibernate core team member
cageface 5y ago
Building SQL queries by gluing strings together is tedious and error prone. So you write a lot of helper functions to build queries for you and pretty soon you've invented your own crappy ORM. Why not save a lot of time and bugs and use a battle tested ORM and drill down to SQL for the queries that really matter instead?
- mrweasel 5y ago
  Or you rewrite you queries so that you can use prepared statements. You’re right that we should avoid gluing strings together, but in most cases we can use prepared statements. There’s also a middleground where developers learn to use the ORM better. I’ve seem people get terrible performance using the Django ORM, but after a rewrite, redesigning the queries and using the more advanced features performance would improve massively. The problem is that need to be able to write the SQL and then mentally backport to the ORMs syntax. We’ve had customers complain about poor database performance. When we find the horrible queries generated by their ORM it’s frequently easier for the developer to just request more hardware or ask if we can: “performance tune” the database.
  - cageface 5y ago
    Prepared statements are a good tool to have in your arsenal but for the majority of the queries you need an ORM will be fine. It doesn't absolve you of the need to understand SQL but it does save a huge amount of time and generally results in easier to follow code.
    - nicoburns 5y ago
      We’ve had the opposite experience. We had a mix of irk code and raw SQL, and we’ve found that the SQL is much more readable. New code is all being written in SQL. Exception is insert and upsert queries which only ever write to one table and involve a lot of boilerplate.
- chousuke 5y ago
  There's a difference between an ORM and a query builder. Full-blown ORMs often allow you to pretend that all you have are "regular" objects that just happen to do database queries when you access them; and that's the kind of ORM that often leads to inefficient database access and fragile code when the program throws an exception when you just wanted to iterate over a list because that iteration actually caused a fetch from a database that happened to have a failover event. With a query builder, you can still use the database in a type-safe way and without gluing strings together, but accessing the database is also more explicit, so mistakes are harder to make. It's fine to represent the result of a database query as a sequence, but its type and interface should be different from that of eg. a list datastructure, because it can fail. similarly, if you have "User" objects representing users, it needs to be explicit which methods fetch data from the database and which use only in-memory properties that code may freely access. Preferably, have different types for "UserInDB" and "User" altogether, with some glue to go between them.
watt 5y ago
I've worked on a real-life product built using MyBatis, which you'd think is supposed to be best of both worlds - non connected DTOs, seamlessly filled out from SQL statements you write in the mapping configuration, etc etc. In practice the developers go overboard with SQL - the native-first SQL actually makes for quite confusing data model. There is value in clarity that limitations of Hibernate model brings or promotes. With MyBatis approach the underlying DB can contain incredibly bizarre joins, crazy FKs, you find aggregation functions in queries trip you up, massive views used under the hood, triggers make appearance to confuse you, the list just goes on. (The reason this happens is as years tick by, extra requirements get fitted into SQL model by doing these "clever hacks" and avoiding re-architecting. The kludges pile up, it's done because it's possible to do so, and every little decision seems like fair tradeoff when made in isolation. End result = massive pile of confusion.) You think staying close to SQL is the salvation, but really it's just another way to hang yourself. I will not argue it's possible to do excellent work, but in no way it's guaranteed.
- eska 5y ago
  Not to be rude but your comment can be summarized as „one can mess up with SQL as well“, which is kind of „duh“. Absolutely every technology can be criticized this way. The more important point is that the layers on top of SQL always lead to horrible performance as soon as something non-trivial is done. And the trivial parts would’ve been trivial in SQL as well. People just really hate learning SQL to the extent that they implement their own, worse query language instead of wielding SQL with skill.
kaba0 5y ago
ORMs are made primarily for OLTP workloads, and they are the primary means of converting SQL results into objects. There is nothing inherently slow about Hibernate (other than people not knowing how to use a tool and blaming it), and frankly, providing a unified SQL dialect that ports over another DB is a plus.
jonathanlydall 5y ago
C# person here and big fan of Entity Framework (but I have used NHibernate in the past). I find the the main benefit of ORMs is type safety. Provided you're using the ORMs to also manage your schema (which you really should if you're using an ORM), then the compiler can guard you from a whole class of mistakes. You're also able to change table and column names with trivial effort and without fear of missing updating some SQL query string somewhere and only finding out during runtime that something is wrong. While it's possible to write LINQ which results in bad SQL, if you didn't have an ORM it would still be possible for developers to write bad SQL anyway. Either way your developers should understand SQL at least a bit and be able to use something like SQL Profiler to ensure that their queries are performant. There is no substitute for competent developers. There is a performance overhead to Entity Framework in the way it tracks changes to objects in contexts. If you're needing to work with a lot of objects from/to a database, then for these particular use cases you can opt out of some of these convenience features to avoid the performance costs. ORMs are an incredibly useful tool if the trade-offs make sense for your project and you know how to use them correctly. But as with any tool, if you use it inappropriately, you're going to have a bad time.
vladmihalcea 5y ago
I've been using Hibernate for 17 years and never had any performance issue with it. Want to know my secret? It's very simple. I just read the manual in 2004. After using it successfully for so long, I wrote a best-seller about how to get the most out of it: https://www.amazon.com/High-Performance-Java-Persistence-Vlad-Mihalcea/dp/973022823X https://www.amazon.com/High-Performance-Java-Persistence-Vla... And, just because afterward I even worked on Hibernate to add all sorts of performance improvements to it, it doesn't mean I don't love SQL. In fact, I happen to run a High-Performance SQL training too: https://vladmihalcea.com/trainings/high-performance-sql/ https://vladmihalcea.com/trainings/high-performance-sql/ Your comment is based on a very common misconception that Hibernate aims to replace SQL. If that were true, then why do you think Hibernate has been offering the createSQLQuery (a.k.a. createNativeQuery) since 2002?

tuatoru 5y ago

What ORMs have taught me: Just Learn SQL https://wozniak.ca/blog/2014/08/03/1/index.html https://wozniak.ca/blog/2014/08/03/1/index.html

Rapzid 5y ago
I like how the very first paragraph walks back the title.

gunnarmorling 5y ago

Hibernate isn't at all meant to avoid understanding or writing SQL; rather, it is meant to map result sets of queries to managed object graphs, track mutations to the loaded graphs, and synchronize those changes efficiently back to the database. The SQL generated by Hibernate is as good or bad as you tell it to; something like inappropriate config causing the n+1 SELECT you describe will instantly show up in any decent dev workflow. You're not bound to JPQL, you can very well use SQL directly too if that benefits your situation. As any powerful tool, Hibernate ORM requires good knowledge of it in order to use it efficiently and effectively. Use it if you have the problems which it solves; don't use it, if you don't have those problems. Disclaimer: former Hibernate core team member

cageface 5y ago

Building SQL queries by gluing strings together is tedious and error prone. So you write a lot of helper functions to build queries for you and pretty soon you've invented your own crappy ORM. Why not save a lot of time and bugs and use a battle tested ORM and drill down to SQL for the queries that really matter instead?

mrweasel 5y ago
Or you rewrite you queries so that you can use prepared statements. You’re right that we should avoid gluing strings together, but in most cases we can use prepared statements. There’s also a middleground where developers learn to use the ORM better. I’ve seem people get terrible performance using the Django ORM, but after a rewrite, redesigning the queries and using the more advanced features performance would improve massively. The problem is that need to be able to write the SQL and then mentally backport to the ORMs syntax. We’ve had customers complain about poor database performance. When we find the horrible queries generated by their ORM it’s frequently easier for the developer to just request more hardware or ask if we can: “performance tune” the database.
- cageface 5y ago
  Prepared statements are a good tool to have in your arsenal but for the majority of the queries you need an ORM will be fine. It doesn't absolve you of the need to understand SQL but it does save a huge amount of time and generally results in easier to follow code.
  - nicoburns 5y ago
    We’ve had the opposite experience. We had a mix of irk code and raw SQL, and we’ve found that the SQL is much more readable. New code is all being written in SQL. Exception is insert and upsert queries which only ever write to one table and involve a lot of boilerplate.
chousuke 5y ago
There's a difference between an ORM and a query builder. Full-blown ORMs often allow you to pretend that all you have are "regular" objects that just happen to do database queries when you access them; and that's the kind of ORM that often leads to inefficient database access and fragile code when the program throws an exception when you just wanted to iterate over a list because that iteration actually caused a fetch from a database that happened to have a failover event. With a query builder, you can still use the database in a type-safe way and without gluing strings together, but accessing the database is also more explicit, so mistakes are harder to make. It's fine to represent the result of a database query as a sequence, but its type and interface should be different from that of eg. a list datastructure, because it can fail. similarly, if you have "User" objects representing users, it needs to be explicit which methods fetch data from the database and which use only in-memory properties that code may freely access. Preferably, have different types for "UserInDB" and "User" altogether, with some glue to go between them.

watt 5y ago

I've worked on a real-life product built using MyBatis, which you'd think is supposed to be best of both worlds - non connected DTOs, seamlessly filled out from SQL statements you write in the mapping configuration, etc etc. In practice the developers go overboard with SQL - the native-first SQL actually makes for quite confusing data model. There is value in clarity that limitations of Hibernate model brings or promotes. With MyBatis approach the underlying DB can contain incredibly bizarre joins, crazy FKs, you find aggregation functions in queries trip you up, massive views used under the hood, triggers make appearance to confuse you, the list just goes on. (The reason this happens is as years tick by, extra requirements get fitted into SQL model by doing these "clever hacks" and avoiding re-architecting. The kludges pile up, it's done because it's possible to do so, and every little decision seems like fair tradeoff when made in isolation. End result = massive pile of confusion.) You think staying close to SQL is the salvation, but really it's just another way to hang yourself. I will not argue it's possible to do excellent work, but in no way it's guaranteed.

eska 5y ago
Not to be rude but your comment can be summarized as „one can mess up with SQL as well“, which is kind of „duh“. Absolutely every technology can be criticized this way. The more important point is that the layers on top of SQL always lead to horrible performance as soon as something non-trivial is done. And the trivial parts would’ve been trivial in SQL as well. People just really hate learning SQL to the extent that they implement their own, worse query language instead of wielding SQL with skill.

kaba0 5y ago

ORMs are made primarily for OLTP workloads, and they are the primary means of converting SQL results into objects. There is nothing inherently slow about Hibernate (other than people not knowing how to use a tool and blaming it), and frankly, providing a unified SQL dialect that ports over another DB is a plus.

jonathanlydall 5y ago

C# person here and big fan of Entity Framework (but I have used NHibernate in the past). I find the the main benefit of ORMs is type safety. Provided you're using the ORMs to also manage your schema (which you really should if you're using an ORM), then the compiler can guard you from a whole class of mistakes. You're also able to change table and column names with trivial effort and without fear of missing updating some SQL query string somewhere and only finding out during runtime that something is wrong. While it's possible to write LINQ which results in bad SQL, if you didn't have an ORM it would still be possible for developers to write bad SQL anyway. Either way your developers should understand SQL at least a bit and be able to use something like SQL Profiler to ensure that their queries are performant. There is no substitute for competent developers. There is a performance overhead to Entity Framework in the way it tracks changes to objects in contexts. If you're needing to work with a lot of objects from/to a database, then for these particular use cases you can opt out of some of these convenience features to avoid the performance costs. ORMs are an incredibly useful tool if the trade-offs make sense for your project and you know how to use them correctly. But as with any tool, if you use it inappropriately, you're going to have a bad time.

vladmihalcea 5y ago

I've been using Hibernate for 17 years and never had any performance issue with it. Want to know my secret? It's very simple. I just read the manual in 2004. After using it successfully for so long, I wrote a best-seller about how to get the most out of it: https://www.amazon.com/High-Performance-Java-Persistence-Vlad-Mihalcea/dp/973022823X https://www.amazon.com/High-Performance-Java-Persistence-Vla... And, just because afterward I even worked on Hibernate to add all sorts of performance improvements to it, it doesn't mean I don't love SQL. In fact, I happen to run a High-Performance SQL training too: https://vladmihalcea.com/trainings/high-performance-sql/ https://vladmihalcea.com/trainings/high-performance-sql/ Your comment is based on a very common misconception that Hibernate aims to replace SQL. If that were true, then why do you think Hibernate has been offering the createSQLQuery (a.k.a. createNativeQuery) since 2002?