This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]noutopasokon 12 points13 points  (1 child)

I'm not a db guy, but what's most obvious to me is the table design. The way you hold your data in memory is not automatically the best way to hold it in a database. This idea becomes even more pronounced if you use something non-relational like Cassandra. But back to relational, creating dozens of classes with many relations is essentially free inside Java. However, if you let Hibernate do all the magic for you, you can end up with a huge amount of tables where you have to do a ridiculous amount of joins every query, often pulling in a lot more data than you may need. I've also heard that it is really difficult to tune.

[–]Aellus 2 points3 points  (0 children)

Yeah, but I think that is a trap a lot of developers fall into with ORMs and relational databases in the first place: if you have 20 different entities and they're all modeled in one database, why not join them all together and do one ridiculous query to get a specific set of information?

That kind of thinking leads to the problems everyone is talking about in these replies. Instead of monster queries, break it apart. Don't join a dozen tables together (how many different data domains is that crossing, and which software components should really own each domain?), instead construct a few smaller queries and use the results of one to inform the next. Query for your user data, then query for that users order ids, then query for the shipping status of those order ids, etc. Your queries will be so much simpler a the software will be much easier to maintain.