The motivation for using composite keys is usually based in some inherently
unique aspect of the data, which means the composite key will be meaningful (tied
to the data) rather than meaningless (tied to the database only). It is usually much
more resilient to assign a meaningless primary key used only within the database.
That way, data integrity is internal to the database rather than being tied to an external
system or process.
As an example, consider a database that tracks U.S. members by their driver??™s license
numbers. A candidate key would be {Issuing state, License number}. One immediate
advantage of a meaningless key is that integer values are easier to represent than lists; it
is easier to refer to a record as 12345 than as [IL,1234]. This makes foreign keys much
simpler, and it simplifies web services and other protocols used for interoperability.
But the most basic problem is that a primary key is usually treated as a unique, stable
identifier for a record. A composite key may not actually be unique in practice
and may even change. If you were to use the preceding composite key, you should be
prepared to answer questions like:
??? What happens when a member moves or has a new license number issued?
??? What happens if some inherent characteristic of the key changes? For example,
how would you handle it if license numbers were always 9 digits and changed to
10? This is a problem in general with keying off of meaningful data.
Pages:
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178