SQLアンチパターン [大型本]
では、カンマ区切りなどのフォーマットのリストを
一つの列に格納するのは避けるべきとしています。

例えば、『担当者マスタ』と『問合せ受付テーブル』が存在し、
その関係が当初、1:Nとして設計されていました。
1件の「問い合わせ」を1人の担当者が受け持つという想定です。
ところが、複数の担当者が1件の「問い合わせ」を担当したいという
要望が出てきました。その対応として、『問合せ受付テーブル』の
「担当者ID」列サイズを大きく拡張し、そこに複数の担当者IDを
カンマ区切りで格納するわけです。

担当者マスタ
------------------
ID  | 名前
------------------
101 | 富山A子
102 | 福岡B美
103 | 大阪C男
------------------

問合せ受付テーブル(他の列は省略)
------------------
KEY  | 担当者ID
------------------
key1 | 101,103
key2 | 102
key3 | 103,101,102
------------------

これを避けるべき理由として、以下を上げています。
1.『問合せ受付テーブル』を担当者IDで検索する場合、等価検索できない。
2.検索時にインデックスが使われない。
3.「名前」を取得したくとも、担当者マスタと結合できない。
4.etc

避けるべき理由として、異論はありません。

個人的に付け加えるなら、以下のようなケースもアンチパターンとしたいところです。

問合せ受付テーブル
----------------------------------------------
KEY  | 担当者ID_1  | 担当者ID_2  | 担当者ID_3
----------------------------------------------
key1 | 101            | 103           |
key2 | 102            |                 |
key3 | 103            | 101           | 102
----------------------------------------------

これでは、登録できる担当者数に制限ができます。
また、「名前」を取得するために、ID列数分、担当者マスタを結合する必要があります。

SELECT KEY, B.名前, C.名前, D.名前
FROM  
 問合せ受付テーブル A
    LEFT OUTER JOIN 担当者マスタ B ON A.担当者ID_1 = B.ID
    LEFT OUTER JOIN 担当者マスタ C ON A.担当者ID_2 = C.ID
    LEFT OUTER JOIN 担当者マスタ D ON A.担当者ID_3 = D.ID

結合するテーブル数が多くなれば、それだけコストがかかりパフォーマンスが落ちます。

解決策は、『担当者マスタ』と『問合せ受付テーブル』の
N:Nの関係性を表す交差テーブルを持つことです。

問合せ受付担当者テーブル
------------------
KEY  | 担当者ID
------------------
key1 | 101
key1 | 103
key2 | 102
key3 | 103
key3 | 101
key3 | 102
------------------

これならば、担当者IDで検索する場合、等価検索できますし
インデックスの効果も期待できます。
登録できる担当者数の制限もありません。

ただ、『問合せ受付テーブル』の情報と一緒に
「名前」を取得しようとする場合は注意が必要です。
単純に三つのテーブルを結合すると、

--------------------------------
KEY  | 担当者ID    | 担当者名
--------------------------------
key1 | 101         | 富山A子
key1 | 103         | 大阪C男
key2 | 102         | 福岡B美
key3 | 103         | 大阪C男
key3 | 101         | 富山A子
key3 | 102         | 福岡B美
--------------------------------

となります。
一覧画面で問合せ受付テーブルを表示し、そこに「担当者名」も表示しようとする仕様では
担当者が増えるたびにレコード件数が増えて表示されてしまう不具合が出てしまいます。

...今となっては懐かしい思い出です(汗)。

結局、一覧画面表示用に『問合せ受付テーブル』に「担当者名」を
カンマ区切りで持つようにしました。

問合せ受付テーブル
------------------------------------
KEY  | 担当者名
------------------------------------
key1 | 富山A子,大阪C男
key2 | 福岡B美
key3 | 大阪C男,富山A子,福岡B美
------------------------------------

「担当者」の登録、更新、削除があるたびに「担当者名」を更新します。

本書では、『カンマ区切りフォーマットのデータが必要で、かつリスト内の
各要素への個別アクセスが不要な』場合にアンチパターンを用いてもよいとしています。

表示用と割り切れば、このようなデータの持ち方も「あり」と考えます。