dm_notes: Documentum Notes

I always have an unanswered question, when ever I see the “r_accessor_name”, “owner_name”, authors, users_names (of a dm_group) and at many places where ever CS refers to a user. Documentum stores the “user_name” in all the above attributes. Typically the “user_name” is “Last name, First Name” and “user_os_name” & “user_login_name”  is generally the unique login user_id in a corporate network.

Why doesn’t CS store the r_object_id of the user where it has to refer to a user, as it is unique, immutable in a repositories lifetime and is also maintainable.
dm_user is a content less object,  It can’t be version-ed.  (You can however update the object properties but you can’t create version this object; i_vstamp tracks the no. of updates) .
So invariably your r_object_id always refer to the same object (version).

If the CS would have used the r_object_id instead of user_name across all objects, it would have been more manageable.

Here are few I believe that create trouble:

• A user name correction or a rename would have been easier. (Ex.: The maiden name change due to marital status or mis-spelled name)
  • Need to change the name on all objects or deactivate the user and create the same user as a new user
  • Need to change the name in all groups defined.
  • A scenario where there are 2 users with the same name.
• User deletion would have been easier and maintainable. ( Delete the user and run a script to remove all the orphan object ids referred by the objects)
• Better disk space utilization. Consider a scenario where there are 10 users (authors) on each object and there are 1000 objects in the repository. Assume an average user_name attribute takes 20 bytes (this would be the minimum I guess). So the space consumed by these users for each version of the object is 10* 20  bytes * 1000 objects = 200,000 bytes. Same scenario with r_object_id 10 users * 16 bytes * 1000 objects = 160,000 bytes a saving of 4000 bytes (4K approx).  Additional versions would save further on space. ( Disk space is inexpensive now but how about maintainability)

The only reason I see the benefit in having the user_name across all objects is the “performance factor”, the CS doesn’t require to fetch the Full name everytime you access a object as it is directly stored currently. But the same could easily be atained through object caching (already supported by the server).

Why it has been designed this way any specific reason for this or it was just overlooked during intial design phase?

Expert comments are welcome.