Observations:
It seems like for most OLAP applications; those applications where the majority of the requirements are real-time read operations (reporting, searching, number crunching, etc... where data cannot necessarily be cached) may be best suited for a JDBC type solution as opposed to using an ORM solution. I think this is because an optimized query or stored procedure can retrieve data faster than drilling into an object graph and its respective relationships (n+1 problem).
It seems like for most OLTP applications; those applications where the majority of the requirements are write operations (CRUD) are best suited for an ORM solution. This is because the SQL required for executing these operations is easily extrapolated from meta data and therefore eliminates the mundane task of having to write and maintain.
Question:
For those applications which are both OLAP and OLTP, then why not use both types of solutions? For example, let's say I have a master-detail type report which does a lot of number crunching and is very complex which returns rows where each row represents a record detail. Clicking on a row is a simple query returning the contents of that row to a detail page. For the report query, I may use a stored procedure or an optimized query. When I click on a row, I leverage my ORM solution retrieving the details with a primary key.
It seems like this would solve both problems:
1. Use ORM to handle the simple CRUD operations. Reduce the amount of SQL which has to be hand written and maintained.
2. Use straight JDBC to handle complex/optimized data retrievals.
Is this not a reasonable solution? Am I missing something?
/robert
Larry Meadors wrote:
We eliminated lazy loading (it was creating literally thousands of queries), and replaced it with a single stored procedure that we mapped to objects with a RowHandler.
No outer joins + highly optimized data access = happy users.
Larry
On Sun, 13 Mar 2005 08:32:58 -0500, N G <[EMAIL PROTECTED]> wrote:
On Sun, 13 Mar 2005 06:18:36 -0700, Larry Meadors <[EMAIL PROTECTED]> wrote:
For example, on the application I am working on, we changed a screen that accessed a large amount of data. The time to draw that screen changed from over 10 minutes (we killed it after that, and are not sure how long it would have run unchecked) to under one. In the case of smaller sets of data, we went from several minutes to sub-second responses.
You mean changing the app from using Hibernate to iBatis changed the performance from 10 min to under 1 and so on? Is that correct?
Why do you think there was SUCH a drastic change???
NG.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
