どのデータベース テーブル スキーマがより効率的で、その理由は?
"Users (UserID, UserName, CompamyId)"
"Companies (CompamyId, CompanyName)"
また
"Users (UserID, UserName)"
"Companies (CompamyId, CompanyName)"
"UserCompanies (UserID, CompamyId)"
ユーザーと企業が1対1の関係にあるという事実を考えると。
どのデータベース テーブル スキーマがより効率的で、その理由は?
"Users (UserID, UserName, CompamyId)"
"Companies (CompamyId, CompanyName)"
また
"Users (UserID, UserName)"
"Companies (CompamyId, CompanyName)"
"UserCompanies (UserID, CompamyId)"
ユーザーと企業が1対1の関係にあるという事実を考えると。
これは自由回答の質問であり、ビジネス ルールによって異なります。最初のオプションでは、1 つの会社を 1 人のユーザーにのみマッピングできます。多対一の関係を定義しています。
2 番目のスキーマは、複数のユーザーを複数の会社にマッピングできる多対多の関係を定義します。
それらはさまざまな問題を解決し、解決しようとしているものに応じて、使用するスキーマが決まります。
「トランザクション」の観点から厳密に言えば、ユーザー オブジェクトを会社に関連付けるには 1 つの行をコミットするだけでよく、ユーザーが勤務する会社を取得するには 1 つの結合のみが必要なため、最初のスキーマの方が高速です。ただし、ビジネス要件が変化し、複数の会社をユーザーに割り当てる必要がある場合は、2 番目のソリューションの方が適切に拡張できます。
確かに、その制約を考えると、以前のものの方が効率的です。同じ情報を取得するために、クエリ内の結合の数が少なくなります。
いつものように、それは依存します。結合が少なくなり、維持しやすくなるため、私は個人的に回答番号 1 を使用します。結合が少ないということは、テーブルとインデックスのスキャンが少なくて済むということです。
SELECT userid, username, companyid, companyname
FROM companies c, users u
WHERE userid = companyid
よりもはるかに優れています...
SELECT userid, username, companyid, companyname
FROM companies c, users u, usercompanies uc
WHERE u.userid = uc.userid
AND c.companyid = uc.companyid
2 つのスキーマは異なる関係にあるため、比較することはできません。おそらく、テーブルの仕様を確認してから、必要な関係にどちらが適合するかを判断する必要があります。
最初のものは、ユーザーが1 つの会社のメンバーにしかなれないことを意味します(belongs_to 関係)。一方、2 番目のスキーマは、ユーザーが多くの会社のメンバーになることができることを意味します (has_many 関係)。
has_many 関係をサポートできる (または後でサポートする) スキーマを探している場合は、2 番目の関係を使用することをお勧めします。その理由は次のとおりです。
//会社 x のすべてのユーザーをスキーマ 1 で選択 会社からユーザー名、会社名を選択 users.companyid = companies.companyid でユーザーを内部結合 ここで、companys.companyid = __some_id__;
と
//スキーマ 2 を持つ会社 x のすべてのユーザーを選択します 会社からユーザー名、会社名を選択 usercompanies.companyid = companies.companyid での内部結合 usercompanys usercompany.userid = users.userid でユーザーを内部結合 ここで、companys.companyid = __some_id__;
選択テーブルに余分な結合があります。belongs_to 関係のみが必要な場合、2 番目のクエリは本来よりも多くの作業を行うため、効率が低下します。
ユーザーと企業に関しては、「多対1」を意味していると思います-各ユーザーに固有の企業を計画している場合を除きます。
あなたの質問に答えるには、最初のアプローチを使用してください。格納するテーブルが 1 つ少ないと、スペースが減り、クエリで使用する JOIN コマンドが少なくなります。また、さらに重要なことに、目的の入力に正しく一致します。データベース スキーマは、すべての有効なデータの形式を記述する必要があります。形式に適合する場合、有効と見なされます。ユーザーは 1 つの会社しか所有できないため、2 番目のスキーマを使用すると、データベースに誤ったデータが含まれる可能性があります。
User と Company が実際に1 対 1 の関係にある場合、必要なテーブルは 1 つだけです。
(ID, UserName, CompanyName)
しかし、ユーザーと会社の間には1 対多の関係があることを本当に意味していたのではないかと思います。1 人以上のユーザーは会社ですが、会社は 1 ユーザーのみです。その場合、2 テーブル ソリューションは正しいです。
多対多の関係がある場合(会社は複数のユーザーを持つことができ、ユーザーは複数の会社に関連付けることができます)、3 テーブル ソリューションは正しいです。
ここでは、効率は実際には問題ではないことに注意してください。どのソリューションを使用するかは、データの性質によって決まります。