Hi Robert (and thank you Jason and Witold for your interesting insights)
I hope you don't mind if I elaborate a little. This is an important question, and it deserves careful thinking. First off, let's bring this discussion to a higher level. Instead of deciding between Hibernate and jOOQ as concrete implementations of their own domains, let's think about ORM vs. SQL, and their different use-cases. When deciding between an ORM (e.g. Hibernate) and SQL (e.g. jOOQ), the driving question that you should ask yourself is not the question of project complexity. Some of our most demanding customers are using jOOQ on medium-sized schemas with thousands of tables / views. Often, those schemas are extremely normalised and sometimes even deployed on as many as six different RDBMS. jOOQ was specifically designed to work in these scenarios, while keeping the simple use-case in mind as well. So, instead of thinking about project complexity, ask yourself the following questions: *1. Will your data model drive your application design, or will your application design drive your data model(s)?* A main aspect here is the question whether you "care" about your database in the sense of whether it might survive your application. Very often, applications come and go. They may be re-written in Python / JavaScript, etc. 5 years down the line. Or you have multiple applications accessing the same database: Your Java application, some Perl scripts, stored procedures, etc. If this is the case, database design is a priority in your project, and jOOQ works extremely well in these setups. If you don't necessarily "care" about your database in the sense that you just want to "persist" your Java domain somewhere, and this happens to be a relational database, then Hibernate might be a better choice - at least in early stages of your project, because you can easily generate your database schema from your Entity model. *2. Will you do mostly complex reading and simple writing, or will you engage in complex writing?* SQL really shines when reading is complex. When you join many tables, when you aggregate data in your database, when you do reporting, when you do bulk reading and writing. You think of your data in terms of set theory, e.g. your data as a whole. Writing CRUD with SQL is boring, though. This is why jOOQ also provides you with an ActiveRecord-style API that handles the boring parts, when you're operating on single tables (Jason mentioned this). If, however, your writing becomes complex, i.e. you have to load a complex object graph with 20 entities involved into memory, perform optimistic locking on it, modify it in many different ways and then persist it again in one go, then SQL / jOOQ will not help you. This is what Hibernate has originally been created for. *My personal opinion* I believe that data is forever. You should *always* assume that your database survives your application. It is much easier to rewrite (parts of) an application than to migrate a database. Having a clean and well-designed database schema will always pay off down the line of a project, specifically of a complex project. Also, most projects really do 90% reading and 10% writing, writing often not being complex (2-3 tables modified within a transaction). This means that most of the time, the complexity solved by Hibernate / JPA's first and second level caches is not needed. People often misunderstand these features and simply turn off caching, flushing Hibernate's cache to the server all the time, and thus using Hibernate in the wrong way. If, however, you're undecided about the above two axes of decision, you can go the middle way and use jOOQ only for reporting, batch processing, etc. and use Hibernate for your CRUD - in a CQRS (Command Query Responsibility Segregation: http://martinfowler.com/bliki/CQRS.html) style. There are also quite a few jOOQ users who have chosen this path. Last but not least, here are some additional resources: http://www.hibernate-alternative.com (summarises this e-mail) http://www.jooq.org/why-jOOQ.pdf (for your management) but the Hibernate community appears to be dead. May I ask you what made you think this way? Best Regards, Lukas 2015-02-18 21:44 GMT+01:00 Robert Liguori <[email protected]>: > Hi, we've been doing just basic SQL with JDBC... but our next project is > much more complex so we are looking at Hibernate for an ORM solution... but > the Hibernate community appears to be dead. > > Note that I just stumbled upon jOOQ. Are there any shortfalls with jOOQ? > Does it rival Hibernate? > > If I was going to try to sell this API to my management over Hibernate, > what would I tell them? > > Thank you so much, > Robert > > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
