リレーショナルデータベースでリストを使用しても大丈夫ですか？

私はプロジェクトのコンセプトに合わせてデータベースを設計しようとしており、熱く議論されている問題のように思われました。私はいくつかの記事を読んで、フィールドにIDなどのリストを保存することは決して（またはほとんど決して）大丈夫ではないことを示すいくつかのStack Overflowの回答を読んでいます-すべてのデータはリレーショナルでなければなりません

しかし、私が直面している問題は、タスクアサイナーを作成しようとしていることです。ユーザーはタスクを作成し、複数のユーザーに割り当てて、データベースに保存します。

もちろん、これらのタスクを「Person」に個別に保存する場合、1人に0〜100個のタスクを割り当てることができるため、ダミーの「TaskID」列を数十個用意し、それらをマイクロ管理する必要があります。

繰り返しますが、タスクを「タスク」テーブルに保存する場合、ダミーの「PersonID」列を数十個用意し、それらをマイクロ管理する必要があります。これは以前と同じ問題です。

このような問題の場合、何らかの形でIDのリストを保存しても大丈夫ですか、それとも原則を破らずに達成できる別の方法を考えていないだけですか？

調査する必要があるキーワードとキー概念は、データベースの正規化です。

行うことは、割り当てに関する情報を個人またはタスクテーブルに追加するのではなく、その割り当て情報と関連する関係を持つ新しいテーブルを追加することです。

たとえば、次の表があります。

人：

+ ---- + ------------ +
| ID | 名前|
+ ==== + =========== +
| 1 | アルフレッド|
| 2 | ジェダイディア|
| 3 | ジェイコブ|
| 4 | エゼキエル|
+ ---- + ------------ +

タスク：

+ ---- + --------------------- +
| ID | 名前|
+ ==== + ==================== +
| 1 | 鶏に餌をやる|
| 2 | プラウ|
| 3 | 搾乳牛|
| 4 | 納屋を上げる|
+ ---- + --------------------- +

次に、割り当てを持つ3番目のテーブルを作成します。この表は、人とタスクの関係をモデル化したものです。

+ ---- + ------------ + --------- +
| ID | PersonId | TaskId |
+ ==== + =========== + ========= +
| 1 | 1 | 3 |
| 2 | 3 | 2 |
| 3 | 2 | 1 |
| 4 | 1 | 4 |
+ ---- + ------------ + --------- +

次に、データベースがPersonIdおよびTaskIdsがそれらの外部アイテムの有効なIDでなければならないことを強制するように、外部キー制約を設定します。最初の行のために、私たちは見ることができるPersonId is 1ので、アルフレッドに割り当てられTaskId 3、搾乳牛。

ここで確認できるのは、タスクごと、またはユーザーごとに、必要な数の割り当てをできることです。この例では、エゼキエルにはタスクが割り当てられておらず、アルフレッドには2が割り当てSELECT PersonId from Assignments WHERE TaskId=<whatever>;られています。WHEREPersonIdで、その人に割り当てられたすべてのタスクを見つけることができます。

IDを名前とタスクに置き換えてクエリを返したい場合は、テーブルを結合する方法を学習します。

ここで2つの質問をしています。

最初に、列にシリアル化されたリストを保存してもよいかどうかを尋ねます。はい、その罰金。 プロジェクトで必要な場合。 例としては、カタログページの製品成分があり、各成分を個別に追跡しようとする必要はありません。

残念ながら、2番目の質問では、よりリレーショナルなアプローチを選択する必要があるシナリオについて説明しています。3つのテーブルが必要です。1つは人用、もう1つはタスク用、もう1つはどのタスクがどの人に割り当てられているかのリストを保持します。最後の行は、主キー、タスクID、および個人IDの列を持つ、人/タスクの組み合わせごとに1行の垂直です。

あなたが記述しているが間、あなたの場合には、関係「多くの多くの」として知られているPersonとTask。通常、「リンク」または「相互参照」テーブルとも呼ばれる3番目のテーブルを使用して実装されます。例えば：

create table person (
    person_id integer primary key,
    ...
);

create table task (
    task_id integer primary key,
    ...
);

create table person_task_xref (
    person_id integer not null,
    task_id integer not null,
    primary key (person_id, task_id),
    foreign key (person_id) references person (person_id),
    foreign key (task_id) references task (task_id)
);

...フィールドにIDなどのリストを保存することは決して（またはほとんど）できません

あなたが唯一の時間かもしれない単一のフィールドに複数のデータ項目を保存するには、そのフィールドがされている場合でのみ、これまで単一のエンティティとして使用され、決してそれらの小さな要素から作られていると考えられていません。例としては、BLOBフィールドに保存された画像があります。それはたくさんの小さな要素（バイト）で構成されていますが、これらはデータベースにとって何の意味も持たず、すべて一緒にしか使用できません（そしてエンドユーザーには見た目もきれいです）。

「リスト」は定義により小さな要素（アイテム）で構成されるため、ここではそうではなく、データを正規化する必要があります。

...これらのタスクを個別に「Person」に保存する場合、ダミーの「TaskID」列を数十個用意する必要があります...

いいえ。PersonとTaskの間の交差テーブル（弱エンティティ）にいくつかの行があります。データベースは、多くの行を扱うのに非常に優れています。実際、多くの[繰り返し]列を扱うのはかなりゴミです。

whatsisnameによって与えられたニース明確な例。

特定の事前計算フィールドでは正当な場合があります。

クエリの一部が高価で、データベーストリガーを使用して事前に計算されたフィールドを自動的に更新することにした場合、列内にリストを保持するのが正当な場合があります。

たとえば、UIでは、グリッドビューを使用してこのリストを表示します。ここでは、ダブルクリックすると、各行で完全な詳細（完全なリスト）を開くことができます。

REGISTERED USER LIST
+------------------+----------------------------------------------------+
|Name              |Top 3 most visited tags                             |
+==================+====================================================+
|Peter             |Design, Fitness, Gifts                              |
+------------------+----------------------------------------------------+
|Lucy              |Fashion, Gifts, Lifestyle                           |
+------------------+----------------------------------------------------+

クライアントが新しい記事にアクセスしたときのトリガーまたはスケジュールされたタスクによって、2番目の列を更新し続けます。

このようなフィールドは、検索でも使用できます（通常のテキストとして）。

そのような場合、リストを保持することは正当です。最大フィールド長を超える可能性がある場合を考慮する必要があります。

また、Microsoft Accessを使用している場合、提供される複数値フィールドは別の特別なユースケースです。フィールド内のリストを自動的に処理します。

ただし、他の回答に示されている標準の正規化された形式にいつでもフォールバックできます。

要約：通常の形式のデータベースは、データモデリングの重要な側面を理解するために必要な理論モデルです。ただし、当然のことながら、正規化ではパフォーマンスやその他のデータ取得コストは考慮されません。それはその理論モデルの範囲外です。ただし、実際の実装では、リストまたはその他の事前計算（および制御）された複製を保存することがしばしば必要です。

上記に照らして、実際の実装では、完全な正規形に依存して20秒実行するクエリ、または0.08秒かかる事前計算値に依存する同等のクエリを優先しますか？ソフトウェア製品の遅さを嫌う人はいません。

与えられた2つのテーブル。それぞれを独自のID（PersonID、TaskID）を持つPersonおよびTaskと呼びます。基本的な考え方は、3つ目のテーブルを作成してそれらをバインドすることです。このテーブルをPersonToTaskと呼びます。少なくとも、自身のIDと他の2つのIDが必要です。だから、誰かをタスクに割り当てることになると、Personテーブルを更新する必要はなくなり、PersonToTaskTableに新しい行を挿入するだけで済みます。また、メンテナンスがより簡単になります。タスクを削除する必要があるのは、TaskIDに基づいたDELETEになり、Personテーブルと関連する解析を更新する必要がなくなります。

CREATE TABLE dbo.PersonToTask (
    pttID INT IDENTITY(1,1) NOT NULL,
    PersonID INT NULL,
    TaskID   INT NULL
)

CREATE PROCEDURE dbo.Task_Assigned (@PersonID INT, @TaskID INT)
AS
BEGIN
    INSERT PersonToTask (PersonID, TaskID)
    VALUES (@PersonID, @TaskID)
END

CREATE PROCEDURE dbo.Task_Deleted (@TaskID INT)
AS
BEGIN
    DELETE PersonToTask  WHERE TaskID = @TaskID
    DELETE Task          WHERE TaskID = @TaskID
END

簡単なレポートや、誰がタスクに割り当てられているのでしょうか？

CREATE PROCEDURE dbo.Task_CurrentAssigned (@TaskID INT)
AS
BEGIN
    SELECT PersonName
    FROM   dbo.Person
    WHERE  PersonID IN (SELECT PersonID FROM dbo.PersonToTask WHERE TaskID = @TaskID)
END

もちろん、もっと多くのことができます。TaskAssignedおよびTaskCompletedにDateTimeフィールドを追加した場合、TimeReportを実行できます。それはすべてあなた次第です

人間が読める主キーがあり、テーブル構造の垂直性に対処することなく、タスク＃のリストが必要な場合に機能します。つまり、最初の表を読みやすくします。

------------------------  
Employee Name | Task 
Jack          |  1,2,5
Jill          |  4,6,7
------------------------

------------------------  
Employee Name | Task 
Jack          |  1
Jack          |  2
Jack          |  5
Jill          |  4
Jill          |  6
Jill          |  7
------------------------

問題は、タスクリストをオンデマンドで保存または生成するかどうかです。これは、リストが必要な頻度、データ行の数、データの使用方法などの要件に大きく依存します。 ..その後、ユーザーエクスペリエンスと要件を満たすためのトレードオフを分析する必要があります。

たとえば、2行をリコールするのにかかる時間と、2行を生成するクエリを実行する時間を比較します。時間がかかり、ユーザーが最新のリストを必要としない場合（* 1日に1回未満の変更が予想されます）、保存できます。

または、ユーザーに割り当てられたタスクの履歴レコードが必要な場合は、リストが保存されていても意味があります。ですから、それはあなたが何をしているのかに本当に依存します。決して言わないでください。

別のテーブルにする必要があるものを取り、それを90度回転させて、別のテーブルにシューホーンします。

itemProdcode1、itemQuantity1、itemPrice1 ... itemProdcode37、itemQuantity37、itemPrice37がある注文テーブルがあるようなものです。プログラムで処理するのが面倒であることに加えて、明日誰かが38個のものを注文することを保証できます。

「リスト」が実際にはリストではない場合、つまり、リスト全体が独立していて、個々の行項目が明確で独立したエンティティを参照しない場合にのみ、あなたのやり方でやります。その場合は、十分な大きさのデータ型にすべて詰め込んでください。

したがって、注文はリストであり、部品表はリスト（またはリストのリストであり、「横向き」を実装するのはさらに悪夢です）。しかし、メモ/コメントと詩はそうではありません。

「大丈夫」でない場合、すべてのWordpressサイトのwp_usermetaに1行にwp_capabilitiesのリスト、1行にdismissed_wp_pointersのリスト、その他のリストがあることはかなり悪いです...

実際、このような場合、ほとんど常にリストが必要になるため、速度が向上する可能性があります。しかし、Wordpressがベストプラクティスの完璧な例であることは知られていません。