Bonnie,

that's the dilemma we have... so far we've stored our values in one generic table (basically ID, Code, Description).
We need to add some features and we are questionning the use of CODE over ID...

Binding directly on the CODE means that it's easy for queries and business rules validation... also good for data conversion and export/import like you pointed out.

Some other people don't like the idea and prefer ID mainly because SQL Server is much more efficient on ID (numbers) than on codes (strings).
Changing this also affects many existing systems and we usually try to be as much backward compatible as possible.

It's almost a religious matter :)

Thank you for your precious input,

Alex