mysql - 将来のスケーラビリティのためにデータベース設計を改善する

Question

ええと、私は何千人ものユーザーが関与する可能性のあるプロジェクトに取り組んでおり、特にエンティティ間の関係が関係する場合、データベースの経験はあまりありません。

私のシナリオを説明しましょう。まず、資格情報を使用してシステムにログインできるユーザーがいます。私たちのシステムには、彼がプロジェクトを作成できるようにするモジュールがあります。これにより、User テーブルと Projects テーブルの間に関係が生まれます。

現在、別のモジュール、つまりチーム作成モジュールがあり、それはそれが言うことを行います。利用可能なメンバーのリストから、好きな人を選んでチームに追加できます。したがって、そのメンバーとチームのテーブルがあります。さらに、メンバーは多くのチームの一員になることができ、チームは多くのメンバーを持つことができ、「ユーザー」もメンバーになることができます。

私は自分でデータベースを設計しましたが、それが良いものか悪いものかはわかりません。さらに、リレーションシップを含むテーブルに挿入または更新する方法を示す優れたチュートリアルを誰かが教えてくれれば、本当にありがたいです。

これまでの私のデザインは次のとおりです。

アップデート

IRC の誰かと議論した後、私は修正されたデザインを思いつきました。ユーザーもメンバーであるため、「ユーザー」と「メンバー」テーブルをマージしました。

私の質問は今でも同じです。私は正しい道を進んでいますか?

Answer 1

長期的に考えているのは素晴らしいことですが、あなたの解決策は長期的にはうまくいきません。

この種の試みがこれまでに行われたのはこれが初めてではありません。以前に失敗した人の知恵に頼ってください。データ モデリングのパターン ブックを読む。

抽象化と正規化。それが、優れた長期的な解決策にたどり着く方法です。

少なくとも The Party Model を読んでください。集団と個人は、実は同じ（抽象的な）ものです。

実際には異なるものを異なるテーブルに入れます。アドレスとメンバーは同じテーブルに属していません。

Answer 2

「私は正しい道を進んでいますか？」という質問は有用ではありません。

いくつかのこと：

• リレーションシップにちなんだリレーション列の名前を付けることをお勧めします。たとえば、最初の図では、プロジェクトの「所有者」を users_user_id と呼ぶべきではありません。これは無意味です。これを「owner_id」またはプロジェクトとメンバー テーブルの関係を意味のあるものと呼びます。
• 2 番目の図では、メンバー テーブル内のメンバーとプロジェクトの間に「多対多」の関係があるように見えますが、複数のプロジェクトの ID をメンバー テーブルに格納する効率的な方法はありません。たとえば、teams_members で行ったのと同じように、これを結合テーブル (projects_members) に分解する必要があります。
• 「teams_members」テーブルには、tm_id という主キーがあります。純粋主義者は、これは間違っていると言うでしょう。そのテーブルの一意の識別子は、member_id と team_id の組み合わせにする必要があります。member_id と team_id の組み合わせの一意性を保証する必要があるため、別の一意の識別子は必要ありません。実際、これは有害です。

ニールが言うように、おそらくこれについて読み始めたいと思うでしょう。Coronel らによる「データベース システム: 設計、実装、および管理」をお勧めします。