Database design, multiple attributes in a single field

Question

Is using one database column for each attribute in an ER-model considered best practice?

I do maintenance on legacy code, and I see a lot of multiple attributes, as well as business logic squeezed into single database columns, and I wonder if there is ever any good reason for doing so.

Example is using prefixes for integer values, say a customer ID where the first two digits represent the customer state, and the following digits, the actual id of the customer. Thus storing two attributes in one field. Another example is using negative customer ID:s for customers that have ended their business, thus storing also information on whether the customer is active or not. Etc etc.

Answer 1

What you have there sounds like an application for a new entry in The Daily WTF, not a sensible database design. Before considering such a thing, read up on database normalisation, and save yourself the headaches.

Answer 2

There are many problems that occur in storing multiple fields in a column. For example suppose you need to update such a column, first you were using 'ab' as customer state but then decide to update it to 'cd'. This will get very messy when multiple fields are stored in one column.

You should checkout Database Normalization to better understand this. http://en.wikipedia.org/wiki/1NF

Answer 3

Storing multiple pieces of information in a column is a violation of the first normal form, and therefore considered very bad in a relational database.