Download Growing Better Software

59
3.5 Preventing chaos
Of course the programmer in the previous story made more
mistakes, most notably storing ISBN and book sequence number
together in a single field, as library book key.
In information analysis, two equals many ­ if we store ’many’
pieces of information in one field, it will no longer be possible to
index by the individual bits of information in the field, which will
impact performance. To solve this, we must have separate fields
containing each snippet of information, and we can index our
table once again.
However, we now see a table containing a compound key field
(containing both ISBN and sequence number), followed by fields
containing its individual components (one field containing the
ISBN, the other field the sequence number). Should we base the
key on its components, or the components on the key? The only
correct answer is neither; they should be independent. This
means that if the sequence number part of a book changes from
5 to 05 to allow for more copies of a book, the key should remain
the same. This prevents the need for running a conversion.
Why not use a combination of fields as primary key? Because it
would require you to use ’many’ fields to identify a record. If you
use 'many' fields to identify a record, and a field needs to be
added, you need to change all code that identifies records of that
type. If you use a single field as identifier, after a change it will
still be a single field. In other words, the single­field key
approach will save you maintenance.
Simply joining the values into a single compound key field
doesn't work. Such keys are not suitable as permanent record
identifiers, as they can be predicted to require changing every
now and then.