0

個人情報とログオンの詳細を含む友人のテーブルを作成したいと考えています。

members テーブルを 2 つのテーブルに分割すると、1 つには最小限の詳細が含まれ、2 つ目にはその他の詳細が含まれます。

または1つのテーブルに残りますか？

メンバーの外部キーを含むテーブルがたくさんあります。

4

3 に答える 3

3

1つのメンバーを複数の詳細セット（つまり、複数の電子メールアドレス、ユーザーグループ、昼間電話、夜間電話、携帯電話など）に関連付ける必要がない限り、1つのテーブル。

于 2009-07-06T13:18:56.563 に答える
3

それは、それらの「その他の」詳細が何であるかに大きく依存します。これはよくある興味深い質問であり、一見しただけでは「難しい」答えはありません。しかし、この問題をより抽象的に考えれば、表現したい特定のものの属性 (「詳細」) 間の実際の関係について、ある程度明確になるかもしれません。

あなたの質問では、友達には「最小限」と「その他」の詳細があると述べています。これらの詳細を「最小限」または「その他」として分類するのではなく、個々の (「原子」) 詳細が友人をユニークにするものによって完全に決定できるかどうかによって分類しましょう。

FriendID や電子メール アドレスなどの主キー (PK) があると思います。この一意の識別子を考慮して、次のように自問してください。「FriendID (または PK として使用している電子メールなど) が 1 つだけ与えられた場合、その友人のどのような詳細を絶対に確信できるでしょうか?たとえば、FriendID=2112 が与えられた場合、私は絶対にその友達の名前、姓、生年月日は知っていますが、その友達の電話番号は複数あるため、完全にはわかりません。

与えられた PK について明確に知っているすべての詳細を 1 つの表にまとめます。さらにデータが必要な詳細 (電話番号の場合は「自宅」や「職場」など) を「子」テーブルに配置し、PK の「親」テーブルに外部キーで戻します。(注: 子テーブルの PK は複合キーになる可能性が非常に高くなります。つまり、親テーブルの PK と差別化要因 (この例では「自宅」や「職場」など) で構成されます。多側の複合キーの 1-M 関係は非常に良好です。)

データベース オタクは、機能依存関係に基づいてこの分解を呼び出します。

于 2009-07-06T14:59:00.310 に答える
0

疑問の余地はありません。論理的に意味がある場合は、常にテーブルを分割してください。

例: フレンド 1: トム ジョーンズはザ バレーに住んでいます。

テーブル:

Friends
Id  Name          Address
1   Tom Jones     1
2   Erin Jones    1

Adresses 
Id Address
1  The valley

そうしないと、常に次のようになります。

Friends
Id  Name          Address
1   Tom Jones     The Valey
2   Erin Jones    The Valley

これは、誤ったクエリにつながります。

これは 1 つの問題に過ぎず、多数の問題があります。たとえば、2 つの電子メール アドレスと 3 つの携帯電話番号がある場合はどうでしょうか。通りの名前が変わり、そこに 5 人の友人が住んでいる場合はどうなりますか?

テーブルが小さいことが確実で、クエリを実行する必要がない場合は、テーブルを 1 つだけ使用できます。しかし、swのようなエクセルや、そのことについては一枚の紙を使用することもできます:-)

ただし、データベースが必要な場合は、データベースを 1 つとして扱います。

問題全体の正規化について読んでください。

于 2009-07-06T13:44:28.487 に答える