Q:

Database Design: Is it bad to keep delimited strings in a database

I've worked on projects before that would store fields in a comma-delimited or pipe-delimited string as a field, which might represent options or something simliar. I was wondering if it was considered bad database design to do this, and relational tables should always be used, or sometimes is it acceptable to store data in this fashion?

A:

Usually, that's a bad idea.
However, there is a balance between normalization and performance.
If the list isn't parsed and is simply displayed as-is, then it would be preferable to store the comma-separated list, but if the list is parsed for individual elements, you should stick to a normalized database schema.

A:

This depends on you. A database field should contain atomic data, that is, the whole value is meaningful but part of the value is not. For example, I might decide to store a person's name in a field called fullname, so the values are John Smith and Mary Jane etc. 
This is correct if for ever more I will always treat these values as one whole and never need to select first name only or last name only, or sort by last name etc.
If the last name or the first name is meaningful to me though, maybe I have to sort by last name in my queries, then I will create two fields firstname and lastName.
In your case, if the delimited items are not interesting at the database level then its fine to keep them in a single field. But if you will need to query by the delimited items then split them into their own fields.

