web-dev-qa-db-ja.com

ドキュメントバージョンフィールドを主キーの一部に設定する必要があります

ドキュメントバージョンを主キーとして設定する必要があります。ドキュメント管理システムで作業しており、これら2つのテーブルがテーブル全体の一部を表しています。

enter image description here

DocumentVersionテーブルで、主キーを（version + documentID）に設定しました。したがって、これがdocumentIDがint型で、バージョンがdecimal（5,2）型である場合に推奨されるアプローチであるかどうか、誰かがアドバイスできますか？または、新しいフィールドを作成して、それをDocumentVersionテーブル内の主キーとして設定した方がよいでしょうか。ありがとう

sql-server-2008-r2tablesurrogate-key
4
john Gu

DocumentVersionテーブルは私には理にかなっています。 2つの列は、DocumentIDの主キーとのDocument関係によってドキュメントを適切に定義し、VersionはDocumentVersionの一意のエントリを作成します。 （名前が示すように。）

2つの異なるデータ型を含む主キーを使用しても問題はないため、INTとDECIMAL(5,2)は同じ主キー内で問題なく共存します。

avoidは、VARCHAR(10)とINTの結合など、不一致のデータ型間の結合を行うことです。これにより、すべてのデータがクリーンな場合でも、結合パフォーマンスに問題が発生する可能性があります。 （もちろん、VARCHARは、別のクラスの問題となるINTに変換されない文字列を保持できます。）

EDIT：使用法によっては、代理PK列DocumentVersionIDが他のテーブルの参照に役立つ場合があります。ただし、バージョンの追跡の整合性のために、DocumentID、Versionは少なくとも_UNIQUE CONSTRAINT_によって強制される必要があります。

例えば。 ... CONSTRAINT Unique_DocumentVersion UNIQUE (DocumentID, Version);

5
RLF

スキーマに問題はありませんが、個人的には にリストされているのと同様の理由で、別のDocumentVersionId列を作成します。他の列を使用できるのにID列を作成する必要があるのはなぜですか。キーフィールドとして？ ：

  • 単一の整数に基づく結合は、複数の列を含む結合よりも効率的です。スキーマには、DocumentVersionに結合している他のテーブルは表示されませんが、私には、最終的に1つ追加する可能性がかなり高いようです。
  • 自動インクリメントのDocumentVersionIdは、クラスター化されたインデックスに適しています。
1
Justin