I have read the following question regarding whether it is best to use objects w
ID: 652355 • Letter: I
Question
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.
Explanation / Answer
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.