I have read the following question regarding whether it is best to use objects with fully or partially populated data members. The 3 suggestions were:
- that perhaps using a fully populated ORM model may not have as much overhead as you might expect (testing requried);
- an incorrect model was being used if only a limited number of items were being populated, and;
- use a ‘lite’ function or entire class/model to access the pieces of information that are needed.
I cannot tell whether the following solution is using the second or the third suggestion, or more likely, neither:
Example / Solution: Using a table for user information, with each row being a user and storing their user information. For most page views, only 3 out of 12 columns are needed to customize the page for the user. Does it make sense to copy these pieces of information over to another table which holds other relevant session information and is also accessed during every pageload? In this case, there is data duplication but for most tasks a single row is fetched with all relevant information. At the end of the session, this row is removed.
Resist the urge to pre-optimize.
You say that for most page views only a 3 out of 12 User entity properties are used. Even if 30 properties were used that’s still pretty lightweight. I wouldn’t spend too much time worrying about performance losses due to unused data being pushed around.
It’s much more economical in terms of dev effort (read: time and money) to consider performance optimizations near the end of the product’s development. At that time, if there are any serious performance problems, a profiler will quickly identify them. And with this data, you can make an informed decision on which performance problems to tackle. You’re ROI on dev time vs performance is much higher this way.
Alternatively, you might ask yourself why only a quarter of your entity’s fields are required in most cases. It might be that your domain model is a bit too coarse and that subdividing your User into different aspects (sub-entities) makes sense.
It’s all hard to tell without actually looking at your code.
Anyway, the main theme of this answer is:
Don’t pre-optimize. Wait until you have sufficient information before devoting large effort to performance.
1
Generally speaking, it is not good to duplicate values unless there is a valid reason. For the above solution, it is definitely not a good idea.
Though it might seem counter-intuitive, ORMs by default (Hibernate) prefer to load and save all the fields of an entity (recommended upto a limit ~50 columns). The main reason is that they can pre-build these SQLs during startup and populate the statement cache for better performance.
If you opt to do dynamic update or dynamically specify user specified columns, such as if you were implementing the server component of an OData implementation, then it might make sense to build in some optimization.
Also, if you are looking at a table that has a large number of columns. This mostly can happen if the “Table per class hierarchy” strategy is used, then you might want to look at crafting specific HQL queries to only select the needed columns.
JPA 2.1 has introduced a feature called Entity graph that addresses this specific issue of partially selecting an object graph.