「全代理」をサポートする正規のソースはありますか？
バックグラウンド 「すべて-PK-必須被サロゲート」のアプローチは、中には存在しないコッドのリレーショナル・モデルまたは任意のSQL標準（ANSI、ISOまたは他）。 正規の本もこの制限を回避しているようです。 Oracle独自のデータディクショナリ方式では、一部のテーブルでは自然キーを使用し、他のテーブルでは代理キーを使用します。これらの人々はRDBMSの設計について1つか2つ知っている必要があるので、これについて触れます。 PPDM（Professional Petroleum Data Management Association）は、同じ標準的な本が推奨する次のことを推奨しています。 次の場合は、代理キーを主キーとして使用します。 自然キーやビジネスキーはありません 自然キーまたはビジネスキーが不適切（頻繁に変更） レコードを挿入する時点では、自然キーまたはビジネスキーの値は不明です。 複数列の自然キー（通常はいくつかのFK）が3列を超えるため、結合が冗長になります。 また、自然なキーは不変である必要があると述べている正規のソースを見つけていません。私が見つけたのは、それらが非常にエスタブルである必要があるということです。 これらの人々はRDBMSの設計についてもある程度知っている必要があるため、PPDMについて触れます。 「全代理」アプローチの起源は、いくつかのORMフレームワークからの推奨に由来するようです。 このアプローチでは、多くのビジネス分析を行う必要がなく、SQLコードの保守性と読みやすさを犠牲にして、迅速なデータベースモデリングが可能になるのは事実です。すべてのテーブルを結合する必要があるなどの日常的なタスクを犠牲にして、将来発生する可能性のあるものや発生しない可能性があるもの（自然なPKが変更されたため、RDBMSカスケード更新機能を使用する必要があります）クエリを実行し、データベース間でデータをインポートするためのコードを記述する必要があります。それ以外の点では非常に順調な手順です（PK衝突を回避する必要があり、事前にステージ/同等テーブルを作成する必要があるため）。 他の議論は、整数に基づくインデックスはより高速ですが、それはベンチマークでサポートされなければならないということです。明らかに、長く変化するvarcharはPKには適していません。しかし、短い固定長のvarcharに基づくインデックスは、整数とほぼ同じくらい高速です。 質問 -「all-PK-must-be-surrogates」アプローチをサポートする正規のソースはありますか？ -Coddのリレーショナルモデルは新しいリレーショナルモデルに置き換えられましたか？