One of the most asked questions when implementing Documentum is how to best design custom object types. Content Server presents everything as objects, even though the data is stored in a relational database. Most custom object types are derived from SysObject (aka dm_sysobject). The SysObject is the basis for most objects in a repository and contains the most common attributes that associated with content (eg object_name, r_creation_date, owner_name, etc). When designing custom types and attributes, there are some common questions you might ask:
- How many subtypes should I create?
- How many sub-levels from dm_sysobject can I create without impacting performance?
- When should I create a subtype object vs custom attribute that can be used to store object type?
Here are some guidelines that I use based on the 10 years I have been working with Documentum.
- Create a corporate/enterprise object type that will be contain custom attributes that is applicable across the enterprise. This custom type is a subtype of dm_document and is not visible to the normal users. Visible custom types will be derived from this corporate object type.
- When creating subtypes, always be concerned about the total number of object types that will be presented to a user during import/content creation process. From a conceptual level, it might make sense to create 20+ object types that map to different documents available at the corporate level. However, it can be troublesome later on when trying to train a user on which type to select when importing if there are too many object types. Try to keep number of visible objects types to 7-10.
- In older versions of Content Server, creating custom object types several levels deep from dm_sysobject would significantly impact performance when querying. This is no longer a real problem these days given the optimization of the Content Server and enhancements to database performance. The main driver in keeping the object hierarchy flat (vs deep) is purely management of custom attributes. Keeping a flat object hierarchy forces users to think about object types and attributes on a enterprise level vs dept level. Organizations that have deep object hierarchies may encounter object migration issues when they need to consolidate object types due to shear number of custom types that have proliferated. Try not to exceed 5 sub-levels below dm_sysobject.
- Create subtype to add custom attributes to the parent type. Do not create sibling types if they do not have unique attributes that would distinguish them from one another. If you want to identify the type, use a custom attribute (eg media_type).
- Do not create custom subtype and/or attributes unless there is a business need to capture that information. Intuitively, you might want to capture all information/metadata related to a document and therefore you create a custom type with all of these custom attributes. Consider this: who is going to enter all of that attrbute values. Minimize the number of attributes that are essential for business purposes (eg searching). If more information is required, try to think of automated ways to populate the information (eg only require zip code, have an automated program that would populate city and state). The same principle applies to custom types. Do not create them unless there is a business requirement to only search for this custom type and exclude other types.
There are many more guidelines I use that are very dependent on the type of application and business rules. Feel free to share your experiences.