Take the 2-minute tour ×

I have a look-up table and we inserted combination of values like case 12 and 20. I am worry about it, but I am not sure whether this is a bad practice. So how this can be harmful?







share|improve this question
add comment

2 Answers

It is not possible to tell from your description exactly what is the problem. However, if the Name column contains any value that is not Just a Name then you design violates Normalization rules.

Uniqueness definition becomes fuzzy, in your example how could you tell where duplication exist in the list (E, C&E, E&C, C)?. Is (C&E) the same as (E&C)?

Expanding on your example, assume that the Name column is combined with a title as well, then looking for "Alex" and "Mrs" can be difficult. For example, how would you write the query? Is it like "Ale Mrs" or "Mrs Alex" - What if someone has the Name of 'Mrs' but actually is a Mr?. What about column separators?

If one can't make an accurate query, then the update will also cause a problem. Would updating value like (C&E) to (C) or (E) be valid? Could you run a query to change all (C&E) to (C&D)? What if (C&D) already exist, would you allow (C&D&D) in this case?

Having said this, this design may work fine in some cases specially when both of the joined columns are mandatory and the data is used strictly for lookup (e.g. Country-State in simple Contact-us form), but I personally don't favor it since there is no real value gained from it.

share|improve this answer
add comment

Depends on whether values such as C, D and E should be atomic from the data management perspective.

For example, for PK = 12, do you ever need to query for or modify D independently from C (or vice-versa)? If yes, storing D inside C&D violates the principle of atomicity and therefore the 1NF, in which case you should split your table into 1:N relationship:

"1" table:


"N" table ({ID, Name} is key):

ID Name
-- ----
12 C
12 D
share|improve this answer
add comment

Your Answer


