Is it best to (1) cache records from a table, or (2) a full object graph, or (3) a multiple partial object graphs depending on the use case?
Let me clarify:
Let’s say I have an Order system with workflow. It contains objects like: Order, OrderLine, Items, Customer, Workplan, Phase, Milestone, Activities etc.
(1) I can put all records from the Order table into cache, and all records from the OrderLines table into cache, and all records from the Items table into cache etc. Probably a terrible idea, because you can’t query the cache very well.
(2) I can put Order objects, including it’s OrderLines, OrderItems, Customer, Workplan, Phases, Milestones etc., into the cache. I don’t like this because I have to update the cached Order object if somethings changes in it’s Orderlines, Orderitems, Items, Customer, PHases, Milestones etc. Another thing is that I don’t know how big the cached object will be of an Order has relations with 10 or 15 other objects and these are all loaded into the cached Order.
(3) I can ‘split’ the object in a part for the Orderdetails, and a part for the wokrflow. This way I have a cached Order object with all relevant Order details. And I have another Cached Order object, with all relevant Workflow details.
Do you guys have any suggestions about how you cache these things?
(I hope it’s clear, otherwise please let me know)
You need to find a balance, between the information that is viewed the most and the information that changes the most.
The order header for example, is likely accessed on every page, for example a basket view? In this case cache it as it’s going to be hit a lot. But milestones on the other hand, how often is that viewed? If you’re only going to view it perhaps once per session if that, then its less likely to need caching as you gain no real benefit.
If you were to cache the whole object model, then you would be constantly updating the cache with data I imagine, for no real benefit, and the overhead of storing it for the session.