On 04/25/2010 06:14 PM, Tom Anderson wrote:
And as Arne said, when you're trying to do something unusual, you may be
outside the limits of what ORM can comfortably do, and you'll be better
off using straight JDBC. Or perhaps a combination of ORM for any CRUDdy
/ domain logicky bits, and JDBC for complex queries.
I inherited something that uses Hibernate, and I'm thinking about
speeding up a few things. I was just thinking about how it would be
difficult to try to speed all the slow stuff up by replacing all the
hibernate stuff with all JDBC queries, and with my experience there's no
chance I'll be doing this. But this approach (combination of ORM and
JDBC) sounds very interesting to me.
Now, my data is all objects - that suits me perfectly. But there is some
information about all those objects I'd like to store in a single table
or maybe two of them, that'd be super-fast to reach, without having to
look for all those parent/children/node/parameters/other links and
without having other issues to think about. I believe that part of the
features would benefit from it a lot in terms of performance.
Now, how common is this approach (combination)? Is there something
really important I should read about this, before starting with the
implementation?
Hibernate can be slow and Hibernate can be fast. It all depends