5

ここで私を助けてくれることを願っています - SQL テーブルの設計について質問があります。C# を使用してデータベースに書き込み、クエリを実行する方法は知っていますが、実際にデータベースを設計する必要はありませんでした。だから私はそれを私たちの興味だけで試してみようと思った.

family_surname という名前のテーブルがあるとします。そのテーブル内には、x 個の family_members が存在する可能性があります。たとえば、2 人から 22 人の範囲です。family_surname に対して family_members を参照するにはどうすればよいですか?

だから私は FAMILY SURNAME Smith、Jones、Brown、Taylor などを持っているでしょう。

そして、Smith には 5 人のメンバーがいて、そこに年齢、身長、体重などを記録したいと思います。ジョーンズには 8 人のメンバーがいる場合がありますが、家族によって異なる場合があります。

メンバーごとに「姓」を8回リストすることは本当に望んでいません。理想的には、姓の行が別のテーブルの対応する行を参照する（または何らかの形で指し示す）ことです。そして、それは私が問題を抱えているところです！

理にかなっているといいのですが。私が言うように、私はただ興味がありますが、2 つのテーブルでこれを行う方法を知りたいです。

とにかく、助けてくれてありがとう、ありがとう。

編集コメントしてくれた人に感謝します-確かにここにいくつかの有用な情報があり、感謝しています。私はいくつかのSQLビットとピースを読んで研究していますが、これまでのところかなり良いです。ありがとう、みんな！

4

4 に答える 4

3

あなたが求めているのは、正規化についての質問です。テーブルは次のようになります。

Create table surname (
    SurnameID int,
    Surname varchar(255)
)

他のテーブルは、I'dを使用して名前を参照します。また、おそらくsurnameidを一意にし、主キーを使用し、自動インクリメントする必要があります。これらはより高度なトピックです。

とはいえ、このように分割するのに名前が適しているかどうかはわかりません。データを正規化する理由の1つは、リレーショナルの整合性を維持することです。この場合、「スミス」を「ジョーンズ」に変更すると、すべてのスミスが一度に変更されることを意味します。あなたの場合、これは問題ではないと思います。

于 2012-05-14T23:04:35.907 に答える
2

はい、データベースの正規化についての学習に関する以前の回答はおそらく正確ですが、初心者向けです....

人の名前 (名と姓) を分解するのは、おそらく少しやり過ぎです。「ジョーンズ」という名前の全員がすべて関連していると想定していない限り。各テーブルをエンティティ/オブジェクトと考えて、それらを現実世界の「オブジェクト」にできるだけ関連付けるようにしてください。人を一意に識別するには姓と名の両方 (最低限) が必要なため、そのように正規化するべきではありません。

描画したシナリオでは、PersonId、FirstName、LastName を持つ Persons テーブルが必要です。必要に応じて、他の情報を格納する別のテーブル。ただし、人の身長、体重、年齢などは 1 つしかないため、それらは Persons テーブルに格納する必要があります。

したがって、ここで実際に必要なテーブルは 1 つだけです。電話番号や住所などを調べ始めない限り。

于 2012-05-14T23:19:46.710 に答える
0

メンバーごとに「姓」を8回リストしたくない

なんで？現実的な量のデータを測定して、それが実際に問題であると判断しましたか?

姓に固有の追加データ (およびその姓を持つ人物とは無関係) を計画していない限り、姓が独自のテーブルに含まれていなくても問題はありません。あなたは通常のフォームを壊していません。

実際、あなたが提案することは、次の理由により、本当に悪い考えになる可能性があります。

  • 何よりもまず、人の姓を見つけるためだけに JOIN が必要です - パフォーマンスに悪いです。
  • 人物の挿入/変更/削除が複雑になります (そして速度が低下します)。
    • 新しい人を挿入するときは、姓テーブルを検索して、既存のものを「再利用」できるか、新しいものを挿入できるかを判断する必要があります。
    • 変更 (たとえば、妻が夫の姓を名乗る場合) は、削除 (以下を参照) と挿入の組み合わせです。
    • 姓は、誰も持っていなくても存在できますか? いいえの場合、これを強制するための適切な宣言的整合性はありません。せいぜい、いくつかのトリガーを作成する必要があります。
  • 最終的に多くのスペースを節約できない可能性があります。追加のテーブルには、予想されるストレージの節約の多くを「食い尽くす」可能性がある独自のストレージ オーバーヘッド (主キーの「下」のインデックスなど) があります。
于 2012-05-15T19:06:43.510 に答える
0

分解は次のように行うことができます

  1. CREATE TABLE SURNAMES(INT ID, SURNAME VARCHAR2(200))
  2. CREATE TABLE DETAILS(INT ID, FOREIGN KEY(SURNAME_ID) REFERENCES SURNAMES(ID), PARAM1, PARAM2 .....)

分解の大まかなスケッチは

属性のリストを取得します (SURNAME、PARAM1、PARAM2、....)。属性のリストに基づいて、次のキーを推測できます: 1. (SURNAME) 2.(PARAM1,PARAM2...) キーのセットごとに個別のテーブルが作成されます。

于 2012-05-14T23:21:42.313 に答える