1

私はデータベースの初心者としてカウントされるべきだと思うので、質問を初心者の質問として読んでください。現在、次のように、多数のホストの環境変数を保持するテーブルを作成しています。

create table envs ( 
  host varchar(255), 
  envname varchar(255), 
  envvalue varchar(8192), 
  PRIMARY KEY(host, envname)
);

非常にシンプルで、必要なすべてのデータを保持する 1 つのテーブルです。一般的な操作は、特定のホストのすべての環境変数を取得することです。別の操作は、特定のホストの特定の環境変数を取得することです。3 番目の操作の例は、すべてのホストの特定の環境変数を取得し、重複を一覧表示することです。

パフォーマンスは問題になるとは予想されていません。数十のホスト、1 ホストあたり数十の変数、1 秒あたり平均最大 1 クエリになるでしょう。

今、複合主キーを持つことは必ずしも良い考えではないことを読みました。これは上記のユースケースに当てはまりますか? そうであれば、データベースの設計をどのように変更すればよいですか? そうでない場合、上記の 1 つのテーブルのデータベースは、上記の目的に適していますか?

4

3 に答える 3

2

ここでは主キーに問題はありません。主キーのセマンティクスは、キー値の非キー属性値を一意に識別することです。1つのホストと1つのenvnameに対して、最大で1つのenvvalueがあると想定しているので、主キーは完全に理にかなっています。

パフォーマンスの問題を恐れているため、複合主キーに反対する人もいる可能性があります。ただし、パフォーマンスの考慮事項が主キーの選択に影響を与えることはありません。多くのデータベースシステムは、主キーのインデックス構造を自動的に作成します。このインデックス構造の選択は、パフォーマンスに影響を与える可能性があります。ただし、この選択はほとんど手動で変更でき、本当にパフォーマンスの問題がある場合は後で行う必要があります。

1つのテーブルの設計と主キーの選択は問題ありません。

于 2012-11-12T11:28:21.317 に答える
1

今、私は複合主キーを持つことは必ずしも良い考えではないことを読みました。これは上記のユースケースに当てはまりますか？

いいえ。で複合主キーを使用し(host, envname)ます。

それが本当の場合、データベース設計をどのように変更すればよいですか？

該当なし。

そうでない場合、上記の1つのテーブルのデータベースは上記の目的に適していますか？

はい：これは、エンティティ-属性-値モデルとして知られています。

于 2012-11-12T11:27:16.670 に答える
1

一意の値 (ホスト、環境名) を数回保存するため、これは悪い考えです。

ホスト名をsrv01から *srv01_new*に変更するとどうなるでしょうか? テーブル内のsrv01のすべての出現を変更する必要があります。また、ある日、すべてのホストに関する追加情報を保持する新しいテーブルを作成する必要があると判断した場合はどうでしょうか。

ここで、ホスト名を変更する場合は、それらの情報も変更する必要があります。

あなたの質問にたどり着くには：それはパフォーマンスの問題ではなく、正規化の問題です。

通常、データベースは可能な限り正規化する必要があります。十分に興味がある場合は、読み進めてください。

一意のID (int) をプライマリ キーとして、一意の (インデックス)名をホスト名として持つ、ホスト用の 1 つのテーブルを作成する必要があります。

テーブルは、 nameではなく、ホストのidのみを参照する必要があります。このように、ホスト名はデータベース全体に一度だけ保存され、他のテーブルを壊すことなく、好きなように変更できます。

環境名も一意である場合は、ホスト テーブル (id、name) と同じレイアウトを持つ別のテーブルを作成する必要があります。

組み合わせテーブルには、値とともに、ホストのID と環境の ID が格納されます。もちろん、組み合わせた主キーを保持する必要があるため、ホスト/環境のすべての組み合わせは一意であり、簡単にインデックス付けできます。

次に、追加の属性と完全な正規化を使用して、多対多の関係を確立します。

于 2012-11-12T11:33:39.770 に答える