In two of the three cases you mention the encoded data binds to a
physical object or a collection of physical objects. In the third case the encoded data is a time stamp. What is common in all these cases is after assignment if the ID is
NEVER EVER changes. Meeting that condition in most systems is very hard. I have had
conversations like this dozens of times Wouldn’t it be cool to have the Region of the
salesmen encoded in his ID? Sure, but what happens when he move to a different region? Do we change the ID of the salesmen and orphan all his
old records? Or do we keep his old ID which makes the region encoding
a lie? Encoding data into ID violates one of Dr. Codd’s design rules. It
makes the key a functionally related to other facts in the record. Vet very carefully any proposal to have encoding in ID values. If
the business representatives cannot swear a blood oath that the encoded fact
will never change use something else. -----Original Message----- Hi Folks, Should identifiers be dumb? That is, no meaning can be ascribed to
identifiers; they are completely random. Or, should information be encoded into identifiers? What information
should be encoded into them? There are precedents for encoding information into identifiers: 1. In the 2. Books are identified by ISBNs. Encoded within each ISBN is a wealth
of information, including the country, publisher, and the relative size of the
publisher.[2] 3. UUIDs are used in many applications. Encoded within some UUIDs are
the date/time stamp of when the UUID was created, and the network address of
the machine which created the UUID.[3] I suspect there are other examples of identifiers that have information
encoded into them. What are the advantages of encoding information into an identifier?
What are the disadvantages? /Roger [1] Format of VIN: http://en.wikipedia.org/wiki/VIN [2] Format of ISBN: http://www.xfront.com/isbn.xsd [3] Fomat of UUID: http://www.ietf.org/rfc/rfc4122.txt _______________________________________________________________________ XML-DEV is a publicly archived, unmoderated list hosted by OASIS to support XML implementation and development. To minimize spam in the archives, you must subscribe before posting. [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ Or unsubscribe: xml-dev-unsubscribe@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php |