|
Well, in terms of query performance it sounds like a good decision. With an MQT, the data is gathered and stored physically so that the next time you access the data you do not have to go through the machinations of joining, etc. So the same query going against an MQT query can run faster than going against the base tables.
But a lot depends on how static the data is. Are you aware that an MQT is not updated immediately when the underlying base tables are updated? So if you have an MQT joining EMPLOYEE to DEPARTMENT, and then you delete an employee row, that employee will still show up in the MQT until you run a refresh of the data. If the data in the underlying tables is quite volatile, then MQTs are probably not the appropriate choice for you.
My first question would be this: did you test to make sure that performance will be a problem without the MQTs? It may be, but then again, it might not be. With proper database design and appropriate indexing you might be OK without the MQT. This is not a question that can be adequately addressed in an online forum. I suggest that you consider hiring a skilled DB2 consultant for a couple of days to present your design to him/her, and solicit feedback and suggestions. If you are looking for help on a good consultant, YL&A has some good DB2 talent.
|
