> Relational model databases by definition are not supposed to use keys that 
> have no meaning.

You may have stated that backwards… relational model databases by design should 
never, never, never use business data for keys. This was the number one rule 
drilled into me by my college relational database classes. I found this to be 
very wise advice in the real world. It came in handy when building a database 
for vehicles and the suggestion was to use VIN as a primary key since they were 
unique… it turns our that as unique as VIN should be, they are not… it was no 
problem for out database to handle vehicles with the same VIN because we 
followed the non-business-data-for-primary-key rule.

On the other hand, you do model the data after business relations, but the keys 
that tie that relation data need/should never be seen in a well designed 
system. If a user readable key is needed by business, then there should be 
another data piece that the user can read (like an MRN, medical record number, 
or an abbreviation that is unique and human readable) But these should never be 
used to link together data in a structure in primary key foreign key relation.

Just my two cents.


Neil Dennis
4D Developer since 1990

GreaText - Designing Software for the Way You Work
716 East 1850 N
North Ogden, UT 84414


4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com

Reply via email to