Comments on: Truthiness in Data Modeling http://www.architected.info/blog/truthiness-in-data-modeling How people, practices, and information are transformed into relationships and understanding. Fri, 21 Nov 2008 17:33:39 +0000 http://wordpress.org/?v=2.0.6 by: Mike http://www.architected.info/blog/truthiness-in-data-modeling#comment-8736 Wed, 21 Mar 2007 17:49:54 +0000 http://www.architected.info/blog/truthiness-in-data-modeling#comment-8736 Concerning the use of a single ID per person: This not so much an ivory tower concept as something borne of experience: if you omit the single ID per person you will almost inevitably and unfortunately later find that there _is_ a business requirement for such an ID. And while solving the business requirement is trivial if the single ID is initially included in the design, it is often difficult to add the single ID later. Here's a real-world example: a police records management system containing categories such as employees, civilians, police officers, suspects, felons, and victims. Unless you have the single ID you can't easily answer such a question as "How many police officers were convicted of a felony?" or "Has this potential employee ever been a suspect in a crime?" While it may seem counterintuitive, experience has shown that using such IDs usually makes solutions _easier_ rather than harder. So I will usually include such an ID if there is any reason it might prove useful in the future. The cost of the ID is low and the potential savings in future development costs very high. And as you state, the need for such IDs usually arises in systems with very large scope of application. But these are valid applications. As for there being no single version of the truth you are spot on. And the Highlander metaphor is extremely apt: I think I'll borrow it if you don't mind. Concerning the use of a single ID per person:
This not so much an ivory tower concept as something borne of experience: if you omit the single ID per person you will almost inevitably and unfortunately later find that there _is_ a business requirement for such an ID. And while solving the business requirement is trivial if the single ID is initially included in the design, it is often difficult to add the single ID later. Here’s a real-world example: a police records management system containing categories such as employees, civilians, police officers, suspects, felons, and victims. Unless you have the single ID you can’t easily answer such a question as “How many police officers were convicted of a felony?” or “Has this potential employee ever been a suspect in a crime?”

While it may seem counterintuitive, experience has shown that using such IDs usually makes solutions _easier_ rather than harder. So I will usually include such an ID if there is any reason it might prove useful in the future. The cost of the ID is low and the potential savings in future development costs very high. And as you state, the need for such IDs usually arises in systems with very large scope of application. But these are valid applications.

As for there being no single version of the truth you are spot on. And the Highlander metaphor is extremely apt: I think I’ll borrow it if you don’t mind.

]]>