3

データベース システムを構築していますが、テーブルの 1 つの設計に問題があります。

このシステムには、users テーブル、object テーブル、item テーブル、cost テーブルがあります。

コスト テーブル内の一意のレコードは、ユーザー、オブジェクト、アイテム、および年によって決定されます。ただし、アイテムが異なれば、同じ年のレコードが複数存在する可能性があります。

階層は、ユーザー -> オブジェクト -> アイテム -> 年、アイテムごとに複数の一意の年、オブジェクトごとに複数の一意のアイテム、ユーザーごとに複数の一意のオブジェクト、複数の一意のユーザーになります。

コストテーブルを設計する最良の方法は何ですか?

userid、objectid、itemid を外部キーとして含め、userid、objecid、itemid、costyear で構成される複合キーを使用することを考えています。複合キーは設計が悪いと聞いたことがありますが、複合キーの使用を回避するためにこれをどのように構造化すればよいかわかりません。おわかりのように、私のデータベース構築スキルは少しさびています。

ありがとう！

PS問題があれば、これはインターベースデータベースです。

4

3 に答える 3

13

複合キーを回避するには、代理キーを定義するだけです。これは、自動カウンターなどの人為的な値を保持します。

これらの列に一意の制約を定義することはできます (定義する必要があります)。

ところで、複合キーを使用しないことをお勧めするだけでなく、代理キーを使用することもお勧めします。すべてのテーブルで。

于 2009-10-07T15:48:20.817 に答える
6

内部で生成されたキー フィールド (サロゲート キーと呼ばれる) を使用します。CostID のようなもので、ユーザーには表示されませんが、Cost テーブルの各エントリを一意に識別します (SqlServer では、uniqueidentifier や IDENTITY などのフィールドが有効です)。

于 2009-10-07T15:47:37.513 に答える
0

概説した列を正確に使用して複合キーでデータベースを構築してみて、何が起こるかを確認してください。びっくりするかもしれません。これらの4つの列に欠測データがないことを確認し、2つの行が4つの列すべてで同じ値を持たないことを確認すると、データの整合性を保護するのに役立ちます。

複合主キーを宣言する場合、宣言内の列の順序は、宣言の論理的帰結に影響を与えません。ただし、DBMSが作成する複合インデックスにも同じ順序の列があり、複合インデックスの列の順序はパフォーマンスに影響します。

これらの列の1つ、2つ、または3つだけを指定するクエリの場合、インデックスの最初の列がクエリで指定されていない列であると、インデックスは役に立ちません。クエリがどのように私に影響を与えているか、そしてどのクエリを最も高速に実行する必要があるかを事前に知っている場合、これは主キーの列を正しい順序で宣言するのに役立ちます。まれに、2つまたは3つの追加の1列インデックスを作成すると、更新が遅くなる代わりに、一部のクエリが高速化される場合があります。

于 2009-10-09T14:15:33.680 に答える