It should always be kept in mind, however, that such items are primarily identifiers, and their numeric character is usually completely secondary. Their primary function is to identify items in the problem domain, not to represent quantities of any sort.
For example, it almost never makes sense to operate on numeric business
identifiers as true numbers - adding two account numbers, or multiplying
an account number by -1
, are meaningless operations. That is,
one can strongly argue that modeling an account number as a Integer
is inappropriate, simply because it does not behave as an Integer
.
Furthermore, new business rules can occasionally force numeric business identifiers to be abandoned in favor of alphanumeric ones. It seems prudent to treat the content of such a business identifier as a business rule, subject to change. As usual, a program should minimize the ripple effects of such changes.
In addition, String
s can contain leading zeros, while numeric
fields will remove them.
Thus, it seems best to avoid the natural tendency to model numeric business
identifiers as Integer
, and to use String
instead.
The above remarks apply to business identifiers, not primary keys.
Primary keys should almost always be numeric. Business
identifiers are visible to end users, while primary keys are
usually intended only for internal use by the database. Many database designers consider
it a dubious practice to use a business identifer as an actual primary key.