Home > DOCUMENTUM > Don’t Let Your Object Hierarchy Get Too Deep

Don’t Let Your Object Hierarchy Get Too Deep

January 31, 2011

For performance reasons, it is best to keep your object hierarchy as shallow as possible. The reason for this is that each level of the object hierarchy is stored in a separate table in the database. In order to manipulate an object, the Documentum server must join that object type’s tables with the tables of all of the other object types in the hierarchy above it. The more levels in your hirearchy, the more tables that must be joined together. And database joins are very expensive.

For example the following object hierarchy must do 4 joins (one for each level) when you query on plant_maintenance_report.

                dm_document
                                    |
                                    |  
                   Report
                                    |
                                    |
              technical_report
                                    |
                                    |
          plant_maintenance_report

It is advisable to try to collapse this hierarchy. The typical way to do this is to add all the custom attributes to the report object and add an extra attribute that identifies the type of report. You can still query for plant maintenance reports by using a where clause like this: where report_type = 'Plant Maintenance Report'. The resulting type hierarchy will look like this.

                 dm_document
                                    |
                                    |  
                   Report
  1. Scott
    February 8, 2011 at 1:18 PM

    There are definitely two (at least) schools of thought on this. Yes, a shallower object model will reduce the number to table joins the database has to perform. However, lumping all of your custom attributes in a top level object is not ideal either. This makes your object model cluttered and non-optimal and sometimes it is preferable to know the difference between a report and a plant_maintenance_report is more than just a report_type attribute value. For example, a workflow package may need to know the difference between those two types.

    Designing optimal object models is certainly an art AND a science. I believe the happy medium lies somewhere in the middle between flat and not too deep. :-). I usually don’t build models deeper than 4 or 5 levels below dm_document. Here is another good discussion on this topic: http://johnnygee.wordpress.com/2006/09/05/designing-custom-object-types-and-their-hierarchy/

    Thanks for the post.

  2. February 20, 2011 at 8:24 PM

    Unless someone is in it for total masochistic purposes, there is no need to so deep for most business applications and even if there are, there are relatively simple ways to help tune the database to optimize any resulting join. Even EMC’s own documentation states that this was a concern with earlier versions of Content Server but no really since the advent of 6.x on (or probably even 5.3 spx). Besides, of all the things the could slow down or hamper performance, this issue has got to be one of the most overrated relative to the shitty WDK performance of most production Documentum systems or the piss poor execution performance of many typical customization scenarios.

  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: