ユーザーごとに不確定なフィールド数に対応するデータベースを設計する最善の方法？

Question

私は、ユーザーごとに不確定な数のフィールドに対応できるデータベースを設計する方法を理解しようとしています。

たとえば、User1はProject A、B、Cに関与します。User2はProject A、C、E、Gに関与し、User3はProject A、B、C、D、E、F、Gに関与します。

ユーザーが列に表示されているテーブルと、それに関連するプロジェクトを記録する列が7つあります.100人のプロジェクトに巻き込まれているUser4に対応するまで、かなりうまくいきます。私のモデルは、トラックを保持するために100列を必要とします。

最終的に定義する列の数を事前に知る方法はありません。

User1 & User3をProject Bに関連付けることができますが、その後、さらに10,000本のプロジェクトがある場合は、各プロジェクトレコードを調べて、プロジェクトの完全なリストを作成する必要があります。特定のユーザーが関与しているため、非常に非効率的です。

だから...どのように追跡するのですか？ちょうどこれの周りに私の頭を包むことはできません。

私はこれがあまりにも言及されていないか粗大な小学校の場合は私を許してください。

おかげで、

ベン

Answer 1

これらの2つのエンティティ（userとproject）を1つのテーブルに混在させようとしているようですが、これは本当に最適な方法ではありません。

異なるアプローチがちょうどuserとprojectテーブル、一つのエントリからIDフィールドを含むことになる、user_projectsのようなあなたのuserテーブル内のユーザ情報、project表中のプロジェクト情報、および他の「リンク」のテーブルを持つことです各プロジェクトのユーザーごとに

例スキーマ：

SELECT p.projectTitle 
FROM project p INNER JOIN user_projects up ON p.projectID = up.projectID 
WHERE up.userID = 3 

user_projectsテーブルのポイントはに含まれている情報をリンクすることです

：

user (userID, firstName, lastName) 

project (projectID, projectTitle) 

user_projects (userID, projectID) 

はあなたのような何かを行うことができ、ユーザ3用のプロジェクトのタイトルを選択するにはuserとprojectという表があります。

Answer 2

典型的な多対多の関係。

表を作成する必要があります。各エントリは、関係：user_id,project_idとなります。 あるユーザ（id = uid）がプロジェクト（id = pid）に関与している場合、そのテーブルには2つの列を持つレコード（user_id、project_id）があります。

はい、これはこれまで見たことのない人にとっては奇妙に聞こえるかもしれませんが、これはどこにでも作成されており、DBはこのようなテーブルの処理速度で問題ありません。

後で決定した場合、すべてのユーザーがプロジェクトで何らかの役割を担う必要がある場合は、そのテーブルに他のフィールドを追加することができます。