The standard reasons why you wouldn't want to combine the description and the ID is that 1) The key becomes meaningful in the context of the record, and 2) You will not be able to change the description once it becomes part of the key.

Of course, it is easy to propagate key changes throughout a database by cascading UPDATES, but that does not address possible problems with data that had been generated by the database before the key update but is no longer connected to the database. A couple of examples come to mind:

Backup tapes
EDI (Electronic Data Interchange) files, which are still common when dealing with large organizations.

A more concrete example of a possible issue is loading a Drop Down List in a client application with the status choices. Most of the modern development environments like to deal with Key/Value pairs when loading a selection control with data. With the key and description in the same field, more complexity is added each time a selection control is used in the client application because the client must separate the data manually.

There are also issues with sorting and unicode character translation. It would not be good if a client application used a different character encoding - the keys would not match the table rows anymore!

Basically, there are countless reasons not to combine the description and key into one field, these are only a few.

P.S. It wouldn't be a bad idea to get into the habit of using Integers for your keys. They are faster and smaller than most character-based keys, and they don't temp you to use keys that have contextual meaning.

>Hi,
>
>When I have chosen character primary keys, usually I've made them small to save space but to a great extent out of just being used to doing it that way, I guess this is a mentality from the times when space was an issue. But nowadays in certain applications space is not an issue. As an example of what I'm talking about:
>
>Let's say you have an "ORDER" table:
>
>nOrder_id int
>nAmount money
>cStatus_id char(3) -- foreign key
>
>and I have an "STATUS"s table:
>
>cStatus_id char(3) -- primary key
>cDescription -- Status Description
>
>now, my question would be, if space is not an issue, why not increase the size of "cStatus_id" so the entire description can fit in, provided the description is not humongous of course, ex:, instead of "COM" use "COMPLETED", "PEN" use "PENDING","INTRA" use "IN TRANSIT" etc. This is more readable for an administrator or programmer and it makes the programming easier for the programmer.
>
>What considerations would you have? Maybe speed? or not any noticeable speed difference as having smaller keys?
>
>Cons, pros?
>
>Thanks.
>Thanks.