RIMBAA Performance

Summary

Given the generic nature of RIMBAA databases - are there impacts on performance? Isn't the number of joins causing issues?

Skype chat

(relevant extract to be made)

• [18/09/2008 15:45:23] Rene Spronk says: 1. How about performance? - if one uses the RIM as the basis for db tabes, people realize there will be lots of joins, with a performance hit. What's the best practice here ?
• [18/09/2008 15:48:35] Grahame Grieve says: joins shjoins. Who cares. db's are pretty good at these now-a-days. Unless you have a real domain model that establishes a transaction model boundary you can cache around, it's better to use the db server
• [18/09/2008 15:49:06] Grahame Grieve says: sole exception for me is recursive joins - they're not so good. Which is one reason I've deliberately excluded all recursion from the datatypes in R2
• [18/09/2008 15:55:44] Alex Zupan says: 1) we are testing different strategies, different db,different hibernate mapping ..., to reach the optimal solution.
  • We tried the following hibernate mapping strategies :
  • -- Table for class hierarchy (Javasig default mapping)
  • -- Table for concrete class
• But in any case there are too many join.
• and now will try also:
  • -- Table for subclass
• [18/09/2008 15:57:32] Alex Zupan says: I think that in any case there is to do a little tuning on queries on lazy loading and fetch mechanism of hibernate in order to achieve acceptable speed...
• [18/09/2008 15:57:42] Grahame Grieve says: Alex, I will be interested to hear your results - but surprised if anything you do makes much fundamental difference, since the problem is driven by the complexity of the data, not the layout of it
• [18/09/2008 16:01:01] Alex Zupan says: yes, but a little tuning can increase performance, such as default hibernate mapping of Javasig has many relations with lazy = "false". This leads to do many unnecessary queries.