I was having a discussion with a friend of mine about what makes an object (entity) identifiable. The conversation started with different attributes of the object and then we got into a situation where we had to distinguish two objects who had similar attributes.
More often than not in an Enterprise System we are faced with a situation where two objects come across having similar attributes, which primarily (on a higher level) identify them. When we are faced with such situations then the only way out is to identify another attribute attached to the object which is bound to be unique. In a database application we have the primary keys generated by a sequence generator which guarantees its uniqueness. One the commonly used real-world example is Social Security Number in USA. The social security number is bound to be unique. Another unique attribute is the Credit Card number which is supposed to be unique as well.
In light to the above example the question we have is what is the unique identifier of the object. Is that something attached as as attribute to the object or it is the one which defines the object (rather the object itself). The more we think and discuss about it the more we come to a conclusion that there is no fixed rule as such. Both object being its own unique identifier or the object having an attribute which could uniquely identify it have their own pros and cons. COM uses GUID as a unique identifier for the objects created. A GUID is likely to be unique even though it is generated at many computers simultaneously and is done for years without any interruption.
I personally kind of find myself torn between the two approaches. Object being its own unique identifier has the benefits like the two objects can be identified unique even though they have no attributes to identify them. Whereas having an attribute which makes an object unique is that we can always work out a better combination (of attributes) if the current one is no longer able to gurantee the uniqueness.
I would like to hear from our readers what approach they would prefer in such scenarios and your experience as well. Hope this year brings lots of Joy, Happiness and good times to all of us.
Until Next Time... :)
More often than not in an Enterprise System we are faced with a situation where two objects come across having similar attributes, which primarily (on a higher level) identify them. When we are faced with such situations then the only way out is to identify another attribute attached to the object which is bound to be unique. In a database application we have the primary keys generated by a sequence generator which guarantees its uniqueness. One the commonly used real-world example is Social Security Number in USA. The social security number is bound to be unique. Another unique attribute is the Credit Card number which is supposed to be unique as well.
In light to the above example the question we have is what is the unique identifier of the object. Is that something attached as as attribute to the object or it is the one which defines the object (rather the object itself). The more we think and discuss about it the more we come to a conclusion that there is no fixed rule as such. Both object being its own unique identifier or the object having an attribute which could uniquely identify it have their own pros and cons. COM uses GUID as a unique identifier for the objects created. A GUID is likely to be unique even though it is generated at many computers simultaneously and is done for years without any interruption.
I personally kind of find myself torn between the two approaches. Object being its own unique identifier has the benefits like the two objects can be identified unique even though they have no attributes to identify them. Whereas having an attribute which makes an object unique is that we can always work out a better combination (of attributes) if the current one is no longer able to gurantee the uniqueness.
I would like to hear from our readers what approach they would prefer in such scenarios and your experience as well. Hope this year brings lots of Joy, Happiness and good times to all of us.
Until Next Time... :)
3 comments:
You should probably check out Kripke's Naming and Necessity. As I recall, it turns out that treating names as simple attributes is problematic.
In my view both are necessary. Its helpful to identify a object uniquely and also based uniqueness on its attribute(s). Depending on application requirements the developer can choose to leverage either one of them.
Thanks Simon and Venkk,
Yes the context or usages of an entity does play a big role in deciding what attribute is unique. In this post my attempt is to identify a pattern to decide what could identify the object as unique. So far I've found a system generated ID as one of the option. But there are many other options which is equally good.
Post a Comment