Like the previous T-SQL anti-pattern, this is really all about taking advantage of what a relational database management system offers you. The benefits of an RDBMS come from the relational algebra upon which they are based, and in order to get the best outcomes, you need to follow the rules of the game. When it comes to relational database systems, normalization is the primary rule.
I’m not going to go into detail on normalization—that’s a talk of its own (and one which you can read on my corporate site; right now, that’s a sneak preview, as I haven’t given that talk anywhere yet). Basically, there are a whole slew of anti-patterns around not normalizing your data. They include (but are not limited to):
- Non-atomic attributes. Think of a comma-separated list of phone numbers.
- Multi-valued attributes. In this case, you might have a table with attributes ID, Name, PhoneNumber1, PhoneNumber2, and PhoneNumber3.
- Repeated columns. This is very similar to the multi-valued attribute example above; imagine a table with ID, Name, ChemistryScore, EnglishScore, MathScore, ReadingScore, etc.
In each of these examples, you throw away some of the value of a relational database model. By doing that, you make it easier to introduce bad data and can degrade performance—which is ironic, considering that the primary reason people tend not to normalize their data is to try to improve performance.