2011-10-24 28 views
0

データベーススキーマに新しい(SQLiteを使用する予定)。今のところ、データベースには現在複合キー(3列)が含まれているため、私はサロゲートキーを使用することを考えています。これは私のテーブルの大部分に現れます。私は一意キーの3列といくつかの情報を含む1列を含むいくつかのテーブルを持っています。私はまた、1つのテーブルには、固有のキーの3つの列と、外部キー(多くの親)と同じ3つの列が含まれています。これらのテーブルをすべて1つのテーブルにまとめることは、空のフィールドがたくさんあるので意味をなさないようです。サロゲートキーと複合キー

いずれかのピットを選ぶと、ピットが落ちますか?どちらが一般的にプログラミングにとってより便利だと考えられていますか?

ありがとうございます。

答えて

4

各手法には長所と短所があります。

一般に、単一のサロゲートキー列を参照するだけであれば、SQL文とJOINを書く方が簡単です。また、データベースのサイズもかなり縮小します。

一方、サロゲートキーを使用すると、サロゲートキーの一部である情報を取得するために、JOINに少なくとも1つの余分なテーブルを追加する必要があることがよくあります。代理キーの

二つの追加の利点:

  1. 多くのフレームワーク整数プライマリキーフィールドを使用する必要が

  2. 任意の種類のユーザーインターフェイスコントロール(たとえばWebページの入力)にレコードをバインドする場合、識別目的でコントロールに単一の値をエンコードおよびデコードするよりもはるかに簡単です複数の列。

+0

なぜ自動増分PKとサロゲートキーを候補キーとして使用するときに別のテーブルを追加するのですか? SQLite *は常に「int PK」というROWIDを提供しますが、情報はまだ適切な制約を持つモデルでコード化されていることがわかります。挿入時の断片化を低減するという点で「安い」可能性がある別の[候補/カバーリング]インデックスの「費用」。候補インデックスがテーブルを正規化していない場合、[サロゲート] PKが有効な候補ではありません。 –

+2

製品、サブアセンブリ、コンポーネントを含む部品表。サブアセンブリでは、(ProductID、AssemblyName)は一意です。これをComponentでPKとFKとして使用すると、Componentのみを使用してProduct by Componentの使用状況を確認できます。かわりに代理整数の主キーを使用する場合は、その情報を取得するためにサブアセンブリに結合する(またはサブクエリ手法を使用する)必要があります。 –

+0

簡潔な答えをありがとう。サロゲートは、現在のところ、ほとんどのクエリがキーに基づいているとは限りません(ただし、スコアなどの属性に基づいているため)データベースと編集の構築はもっと多くの作業のように思えますが、クエリにはもっと時間がかかることがあります。 – jobobo