> 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 -- Neil Dennis 4D Developer since 1990 GreaText - Designing Software for the Way You Work 716 East 1850 N North Ogden, UT 84414 mailto:[email protected] http://www.greatext.com/ ********************************************************************** 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:[email protected] **********************************************************************
