0

次のようなテーブル Document があるとします。

 _______________________
|        Document       |
|-----------------------|
| DocumentId int PK     |
| (add't fields)        |
|_______________________|

次に、2 番目のテーブルがあるとします。

 _______________________
|    DocumentVersion    |
|-----------------------|
| DocumentId int PK, FK |
| VersionId int PK      |
| (add't fields)        |
|_______________________|

最後に、DocumentVersion を参照する 3 番目のテーブルを作成したいとします。おそらく、各バージョンにアクセスしたユーザーの監査です (User テーブルが存在すると仮定します)。

 _______________________
|   VersionAccessLog    |
|-----------------------|
| DocumentId int PK, FK |
| VersionId int PK, FK  |
| UserId int PK, FK     |
| AccessTime DateTime PK|
|_______________________|

最良の例ではないかもしれませんが、うまくいけば私の質問を説明するのに十分です。

VersionAccessLogに注目すると、次のようになります。

  • PK(DocumentId、VersionId、UserId、AccessTime)
  • FK(DocumentId, VersionId) REFERENCES DocumentVersion
  • FK(userId) リファレンス ユーザー

ここで私の質問は、VersionAccessLog でFK(DocumentId)を作成する必要があるかどうかです。一見すると、キーは不必要に見えます。参照整合性は、DocumentVersion への FK によって強制されます。しかし、関係代数の観点からすると、この鍵は存在するべきでしょうか? 実用的な観点から (必要に応じて SQL Server 2012 を想定)、キーを含めたり除外したりすることによるパフォーマンスへの影響はありますか?

4

1 に答える 1

0

データベースは挿入（子）または削除（親）ごとにFKをチェックするため、追加のキーを含めるとパフォーマンスに影響があります。実用的な観点からは、検証には実際には値がなく、パフォーマンスコストがわずかにあるため、通常、追加のキーは含めません。

スキーマが変更され、DocumentVersionとVersionAccessLogの間のFKが削除された場合は、VersionAccessLogとDocumentの間にFKを追加することを確認します。私がそれを追加するのを見ることができた唯一の他の時は、Has-FKからの関係を逆転させるいくつかのスキーマ認識DAOライブラリが使用された場合であり、それを含めることは価値がありました。

于 2012-12-10T19:20:27.840 に答える