2

一部のアーティストに関する情報を保存するデータベースを設計しています。これらのアーティストは、1 つ以上の組織に所属できます。これらの組織から名前を保存したいだけで、名前だけを主キーとして持つこれらの組織を含むテーブルを作成することを考えています。主キーのフィールドだけを持つテーブルを持つという事実は、概念的なエラーですか? この場合、それを解決するためのいくつかの提案をいただければ幸いです。

4

3 に答える 3

5

主キーのフィールドだけを持つテーブルを持つという事実は、概念的なエラーですか?

それ自体ではありません。すべてのフィールドが PK を構成する完全に正当な状況があります。

この特定のケースでは、組織名がキーですが、それは必ずしもそれが主キーであることを意味するわけではありません。次のように、より小さく (通常は整数)、維持しやすく、それを主キーにする別のキーを「発明」することができます。 :

ここに画像の説明を入力

これは「代理キー」organizarion_idと呼ばれ、その利点には次のようなものがあります。

  • 子の FK はよりスリムになります (文字列全体ではなく、整数のみが子に移行されるため)。
  • を更新せorganization_nameずに を更新できるためorganization_id、この更新を子にカスケードする必要がありません。
  • 小さな整数サロゲートは、より複雑な自然キーよりも ORM に適している場合があります。

短所：

  • さらにJOINする必要があるかもしれません。
  • さらに 1 つのインデックスが必要であり、インデックスを追加するたびにオーバーヘッドが発生します (ヒープベースのテーブルでも、特にクラスター化されたテーブルでは)。

おわかりのように、これはバランスの問題であり、適切な決定を下すのに十分なドメイン知識を持っているのはあなただけです。

注:organization_artist事項のフィールドの順序。特定の組織のアーティストを効率的にクエリする必要がある場合は上記の順序を使用し、特定のアーティストの組織が必要な場合は逆にします。両方向が必要な場合は、これら 2 つのフィールドに (PK の下のインデックスのほかに) 別の複合インデックスが必要になりますが、順序は逆になります。インデックスが 1 つしかない場合は、このテーブルをクラスタ化することを検討してください (DBMS がサポートしている場合)。

于 2012-06-29T22:25:34.380 に答える
1

組織名が変更される状況を処理するために、OrganizationIdが必要です。

また、異なる組織が同じ名前を持っているように見える場合もあります。「ニューヨーク近代美術館」はいくつありますか？（まあ、ニューヨーカーにとっては、たった1人;-)

組織テーブルは、短縮名、住所、連絡先、優先言語などの列を使用して、時間の経過とともに拡張される可能性があります。したがって、テーブルは次のようになります。

 create table Organizations (
    OrganizationId int not null identity(1,1),
    Name varchar(255),
    CreatedBy varchar(255) default system_user,
    CreatedAt datetime default getdate()
)

成熟したデータベースでは、組織が名前を変更したり、マージしたり、場合によっては分割したりすることさえあります。これを処理するには、発効日と終了日をレコードに追加します。

于 2012-06-29T18:26:35.263 に答える
0

このようなものの標準的な方法は、アーティスト用に 1 つのテーブル、組織用に 1 つのテーブル、およびアーティストを 1 つ以上の組織に関連付けるために 1 つの関連付けテーブルを持つことです。

ARTIST (id, firstName, lastName)

ORGANIZATION (id, name)

ARTIST_ORGANIZATION(artist_id, org_id)

組織名は一意である必要がありますが、関連付けを行うことができるように、主キーとして数値 ID を使用することをお勧めします。また、id との関連付けをクエリすると、文字列を検索するよりもパフォーマンスが向上します。

于 2012-06-29T18:31:28.713 に答える