コンマで区切られた複数の外部キーを使用しているのは間違っていますか？

2つのテーブルがあります：DealとDealCategories。1つの取引に多くの取引カテゴリを含めることができます。

したがって、適切な方法はDealCategories、次の構造で呼び出されるテーブルを作成することです。

DealCategoryId (PK)
DealId (FK)
DealCategoryId (FK)

ただし、アウトソースチームはDeal次の方法でテーブルに複数のカテゴリを保存しました。

DealId (PK)
DealCategory -- In here they store multiple deal ids separated by commas like this: 18,25,32.

彼らがしたことは間違っているように感じますが、なぜこれが正しくないのかを明確に説明する方法がわかりません。

これが間違っていることをどのように説明すればよいですか？それとも私が間違っているのかもしれませんが、これは受け入れられますか？

はい、それはひどい考えです。

行く代わりに：

SELECT Deal.Name, DealCategory.Name
FROM Deal
  INNER JOIN
     DealCategories ON Deal.DealID = DealCategories.DealID
  INNER JOIN
     DealCategory ON DealCategories.DealCategoryID = DealCategory.DealCategoryID
WHERE Deal.DealID = 1234

あなたは今行く必要があります：

SELECT Deal.ID, Deal.Name, DealCategories
FROM Deal
WHERE Deal.DealID = 1234

次に、アプリケーションコードで何かを行って、そのコンマリストを個々の番号に分割し、データベースを個別にクエリする必要があります。

SELECT DealCategory.Name
FROM DealCategory
WHERE DealCategory.DealCategoryID IN (<<that list from before>>)

このデザインのアンチパターンは、リレーショナルモデリングの完全な誤解（テーブルを怖がる必要はありません。テーブルは友達です。それらを使用してください）、またはカンマ区切りのリストを取得して分割する方が速いという奇妙に誤った信念に由来しますアプリケーションコードでは、リンクテーブルを追加することはありません（追加することはありません）。3番目のオプションは、外部キーをセットアップできるほどSQLに自信/能力がないことですが、その場合は、リレーショナルモデルの設計とは何の関係もありません。

SQL Antipatterns（Karwin、2010）は、このアンチパターン（彼は「Jaywalking」と呼んでいます）、15〜23ページに章全体を当てています。また、著者はSOで同様の質問を投稿しています。彼が（この例に適用されるように）指摘するキーポイントは次のとおりです。

• 特定のカテゴリのすべての取引のクエリはかなり複雑です（その問題を解決する最も簡単な方法は正規表現ですが、正規表現はそれ自体が問題です）。
• 外部キーの関係なしに参照整合性を強制することはできません。DealCategory nrを削除した場合。＃26、アプリケーションコードで、カテゴリ＃26への参照を探して各取引を調べ、それらを削除する必要があります。これはデータ層で処理されるべきものであり、アプリケーションで処理する必要があることは非常に悪いことです。
• 集計クエリ（COUNT、SUMなど）も、「複雑」から「ほぼ不可能」までさまざまです。すべてのカテゴリのリストとそのカテゴリの取引数のカウントを取得する方法を開発者に確認してください。適切に設計されていれば、それは4行のSQLです。
• 更新はさらに難しくなります（つまり、5つのカテゴリに属する​​取引がありますが、2つを削除して他の3つを追加したい場合）。これは、適切な設計の3行のSQLです。
• 最終的には、VARCHARリストの長さの制限に直面します。4000文字を超えるコンマ区切りのリストがある場合でも、とにかくモンスターが遅くなると解析する可能性があります。
• データベースからリストを引き出し、それを分割し、別のクエリのためにデータベースに戻ることは、本質的に1つのクエリよりも遅くなります。

TLDR：それは根本的に欠陥のある設計であり、うまく拡張できず、最も単純なクエリでさえ複雑さを増し、すぐにアプリケーションを遅くします。

ただし、アウトソースチームは、次の方法でDealテーブルに複数のカテゴリを保存しました。

DealId（PK）DealCategory-ここには、18,25,32のようなコンマで区切られた複数の取引IDが格納されます。

特定の取引のカテゴリのみを照会する必要がある場合、これは実際には良い設計です。

しかし、特定のカテゴリのすべての取引を知りたい場合はひどいです。

また、更新、カウント、結合など、他のことを行うことが非常に難しく、エラーが発生しやすくなります。

非正規化には場所がありますが、同じデータに対して他のすべてのクエリを犠牲にして、1種類のクエリに対して最適化することに留意する必要があります。常に1つのパターンでクエリを実行することがわかっている場合は、非正規化されたデザインを使用すると利点が得られる場合があります。ただし、クエリの種類に柔軟性を必要とする可能性がある場合は、正規化されたデザインを使用してください。

他の形式の最適化と同様に、非正規化を正当化するかどうかを決定する前に、実行するクエリを知る必要があります。

列の複数の値は、第1正規形に反しています。

また、テーブルはデータベースにリンクされるため、速度の向上はまったくありません。最初に文字列を読み取って解析し、次に「取引」のすべてのカテゴリを選択する必要があります。

正しい実装は、DealIdとDealCategoryIdを持つ「DealDealCategories」のようなジャンクションテーブルです。

不正な階層の実装？

また、別のDealCategoryに対するDealCategoriesのFKは、DealCategoriesの階層/ツリーの不適切な実装のように見えます。親ID（いわゆる隣接リスト）関係を介してツリーを操作するのは大変です！

階層を実装するときは、ネストされたセット（読みやすくはあるが修正が難しい）とクロージャーテーブル（全体的なパフォーマンスは最高だが、メモリ使用量が多い-おそらくDealCategoriesには多すぎない）をチェックしてください！