Many problem domains use numbers as business identifiers. Credit card numbers, bank account numbers, and the like, are often simply that - numbers.
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, Strings 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.