An identifier uniquely identifies and entity.

I need to jump ahead, to the design phase for a moment to discuss the declaration of Identifiers.

The Identifier is always, always declared as an "Integer" and a self-incrementing integer, at that. An identifier is never, never declared as any other form (binary notwithstanding). This identifier is the "computer-friendly" primary identifier (primary key).

The reason for this is performance. Most popular Database Management Systems are described as "relational database management systems," but they're not truly "relational database management systems." The relational DBMS simulates the joining of tables via a combination of algorithms and indices. You want the algorithmic processing to occur in CPU memory -- very, very fast -- mesured in Ghzs (gigahertz) -- rather than mass storage, auxiliary memory, which is half-fast (excuse the pun) because it's making calls to devices whose speed is limited to transfer rates of 100 to 200 MB/s -- and those are the fast ones.

So, what do you do with "OrderNumber," "ItemCode" or "AccountNumber" that may be made up of $tring data?

Traditional identifiers that we have inherited from systems that may go back to the 60s or 70s are loaded with identifiers that are declared as alphanumerics. In modern systems, these "legacy" keys are declared as "Secondary Identifiers" and are declared as having an "index." This is the "people-friendly" identifier (secondary key)."

Think about it. "OrderNumber" is an attribute of an Order. It is a physical characteristic of an Order. It identifies an unique order to a person. It has nothing to do with computers, mass storage or DBMSs. "OrderNumber" existed long before the first computer added 2 + 2."