0

私は次のテーブルを持っています:-

ここに画像の説明を入力

IP アドレスは Technology テーブルの複数値の属性であるため (たとえば、サーバーは複数の IP を持つことができます)、 TechnologyIP という名前の新しいテーブルを作成しました。しかし、その主キーは TechnologyID + IP address である必要があります。または、システム以外で生成された値を主キーの一部として定義しないようにする必要があります。

では、technologyIP テーブルの PK は、technologyID + IPaddress ではなく、単一の ID 列 (上記のように) にする必要がありますか?

助けてくれてありがとう。

4

3 に答える 3

1

どちらのソリューションもうまく機能します。一般に、テーブルごとに自動インクリメント PK を使用する方が簡単なので、1 つの ID 列を追加します。

于 2013-06-30T15:08:08.863 に答える
1

この場合、PK を technologyID & IPAddress にします。主キーは通常、基礎となるインデックスに基づいています。このように構造化された PK を使用すると、特定のテクノロジーのすべての IP を引き戻す優れた読み取りパフォーマンスが得られます。

TechnologyIP テーブルに多くの追加属性を追加する場合は、MIT に代理キーが必要ですが、この場合は、非常にうまく機能する自然キーがあります。

于 2013-06-30T15:19:05.010 に答える
1

{TechnologyID, IPAddress} いずれにせよ、同じサーバーに対して同じ IP アドレスが複数回繰り返されないようにするために、自然キーが必要になります。代理キー(自動インクリメント ID 列など)を作成して、既存の自然キーを「削除」することはできません。

選択は「自然対代理キー」ではなく、「自然対自然+代理キー」です。

すべての制約にはコストがかかるため、すべてが等しい場合、唯一の自然キーは安価になります。次のような特定の理由がある場合にのみ、代理キーを作成する必要があります。

  • 子テーブルの FOREIGN KEY をスリムにするため。
  • ON UPDATE CASCADE 参照アクションを回避するため。
  • オブジェクト リレーショナル マッピング (ORM) を「鎮める」ため。

- - 編集 - -

複数のサーバー間で同じ IP を共有したくない場合があることに気付きました。そうですか？もしそうなら、{IPAddress}ではなく、 だけがキーになるはず{TechnologyID, IPAddress}です。

于 2013-06-30T18:52:52.663 に答える