22

基本的に、複数のベンダーの製品データを1つのデータベースに結合する必要があります（もちろん、それよりも複雑です）。このデータベースには、ほとんどのOLTP操作で結合する必要のあるいくつかのテーブルがあります。

私はデフォルトを維持し、主キーとして自動インクリメント整数を使用するつもりでしたが、あるベンダーが独自の「ProductiD」フィールドを提供しているのに対し、残りは提供しておらず、他のベンダーに多くの手動マッピングを行う必要があります次に、テーブルを使用してデータをロードします（最初にデータをProductsテーブルにロードしてから、IDを引き出して、必要な他の情報と一緒に他のテーブルに追加する必要があるため）。

または、製品のSKUを主キーとして使用することもできます。これは、SKUが単一の製品に固有であり、すべてのベンダーがデータフィードでSKUを提供しているためです。SKUをPKとして使用すると、すべてがSKUに基づいているため、データフィードを簡単に読み込むことができます。これは、現実の世界でどのように機能するかを示しています。ただし、SKUは英数字であり、整数ベースのキーよりも効率がわずかに低くなる可能性があります。

私が見なければならないアイデアはありますか？

4

10 に答える 10

46

これは、サロゲート主キーと自然主キーのどちらかを選択します。

私見は常に代理主キーを優先します。その意味は変わる可能性があるため、主キーには意味があってはなりません。製品はおろか、国の名前も変わったり、国ができたり消えたりします。主キーを変更することは絶対にお勧めできません。これは自然キーで発生する可能性があります。

代理キーと主キーの詳細:

では、代理キーが勝ちますか? さて、自然キーの短所のいずれかが代理キーに適用されるかどうかを確認してみましょう。

  • 短所 1: 主キーのサイズ – 通常、サロゲート キーは int 型の単一の列であるため、インデックスのサイズに問題はありません。それはそれが得られるのと同じくらい小さいです。
  • Con 2: 外部キーのサイズ - Con 1 と同じ理由で、外部キーまたは外部インデックスのサイズの問題はありません。
  • 短所 3: 美学 - まあ、それは見る人の目ですが、複合自然キーほど多くのコードを書く必要はありません。
  • 短所 4 & 5: 任意性と適用可能性 – 代理キーは、人や物がデータを提供したくない、または提供できない場合でも問題ありません。
  • 短所 6: 一意性 - 一意であることが 100% 保証されています。それは安心です。
  • 短所 7: プライバシー - 悪意のある人が入手したとしても、プライバシーに関する懸念はありません。
  • 短所 8: 偶発的な非正規化 – 非ビジネス データを誤って非正規化することはできません。
  • 短所 9: 更新のカスケード - 代理キーは変更されないため、更新時にそれらをカスケードする方法について心配する必要はありません。
  • 短所 10: Varchar の結合速度 - 通常は int であるため、一般的に結合が可能な限り高速です。

また、主キーの代理キーと自然キーもありますか?

于 2009-02-26T13:10:37.017 に答える
10

最も単純な内部状況を除いて、常に代理キーを使用することをお勧めします。それはあなたに将来の選択肢を与え、未知のものからあなたを守ります。

SKUのような追加のキーをnull以外にして強制することができなかった理由はありませんが、少なくともサードパーティへの依存を取り除くことで、取得するのではなく、選択するオプションを自分に与えることができます。あなたと後の段階での苦痛な書き直しに耐えます。

自動インクリメントされた整数を使用する場合でも、次の主キーを自分で決定する場合でも、問題が発生します。自動インクリメント方式を使用すると、レコードを簡単に挿入して独自のキーを割り当てることができますが、レコードに与えられたキーを正確に特定するのに問題が生じる可能性があります（また、最大キーを取得しても、元のキーが返されるとは限りません）。

自分で割り当てたキーを使用する傾向があります。これは、より詳細な制御が可能であり、SQLサーバーでは、中央のキーテーブルからキーを取得して、他のユーザーが同じキーを取得しないようにすることができるためです。

DECLARE @Key INT

UPDATE  KeyTable
WITH    (rowlock)
SET @Key = LastKey = LastKey + 1
WHERE   KeyType = 'Product'

このテーブルには、最後に使用されたキーが記録されています。上記のSQLは、そのキーをテーブル内で直接インクリメントし、新しいキーを返し、その一意性を保証します。

英数字の主キーを避ける必要がある理由：

3つの主な問題：パフォーマンス、照合、およびスペース。

パフォーマンス-パフォーマンスコストがありますが、以下のRazzieのように、数字を引用することはできませんが、数字よりも英数字のインデックスを作成する方が効率的ではありません。

照合-開発者は、異なるテーブルで異なる照合を使用して同じキーを作成する場合があります（これが発生します）。これにより、クエリでこれらのテーブルを結合するときに常に「collat​​e」コマンドが使用され、すぐに古くなります。

スペース-Davidのような9文字のSKUは9バイトかかりますが、整数は4バイトしかかかりません（smallintの場合は2、tinyintの場合は1）。bigintでさえ8バイトしかかかりません。

于 2010-02-03T04:09:18.283 に答える
4

自然キーに常に存在する危険は、最初の仮定が現在または将来、制御できない変更が行われたときに間違っていることが証明されるか、または意味のあるフィールドを渡すことができないレコードを参照する必要がある場所であるということです。望ましい (例: 従業員の社会保障番号を主キーとして使用し、/employee.php?ssn=xxxxxxx のような URL を使用する必要がある Web アプリケーション)

「独自の」SKU とベンダー データ フィードに関する私自身の個人的な経験から、完全 で一意の適切な形式の SKU を含むフィードが送られてくると確信していますか?

さまざまなレベルの IT および事務的能力を持つベンダーからフィードを取得するとき、私は次のすべてに個人的に対処する必要がありました。

  • 製品の SKU が完全に欠落している ("")
  • 事務員はデータベースで 999999999 や 00000000 などのプレースホルダー SKU を使用しており、それらを修正したことはありません
  • データ入力やインポートを行う人は、さまざまな製品番号を混同したり、UPC と SCC のようなものを混同したり、それらを組み合わせる方法を見つけたりしています (最後に不可能なチェック ディジットがある SCC コードを見たことがあります。チェックデジットを修正せずにUPCと01または10を追加）
  • 特別な理由、または単なる能力不足により、ベンダーがデータベースに同じ製品を 2 回入力しました (たとえば、同じマザーボードのリビジョン 1 とリビジョン 2 は同じ SKU ですが、ベンダー データベースとデータ フィードには 2 つのレコードとして存在します)。 rev 2.には新機能があるため）
于 2009-02-26T13:21:06.477 に答える
2

自動インクリメントの主キーも使用します。英数字の主キーを持つことによるパフォーマンスへの影響はありますが、あえて数字を挙げることはしません。ただし、アプリケーションでパフォーマンスが重要な場合は、自動インクリメント主キー列を使用する理由がさらに増えます。

于 2009-02-26T13:13:15.187 に答える
1

自動インクリメントされた「意味のない」整数を主キーとして使用することをお勧めします。誰かが製品 ID を再編成するというアイデアを思いついたとしても、少なくともあなたの DB はトラブルに巻き込まれることはありません。

于 2009-02-26T13:09:32.183 に答える
1

代理キー (自動インクリメント INT フィールド) は、テーブル内の行を一意に識別します。一方、Unique Natural キー (productName) は、重複した製品データがテーブルに入るのを防ぎます。

一意のナチュラル キー フィールドを使用すると、2 つ以上の行が同じデータを持つことはありません。

代理キー フィールドを使用すると、自動インクリメント INT フィールドにより行を一意にすることができますが、代理キーはデータと関係がないため、行のデータは一意ではありません。

ユーザー テーブルの例を見てみましょう。テーブルのナチュラル キー フィールド (userName) は同じユーザーが 2 回登録するのを防ぎますが、自動インクリメント INT フィールド (userId) はそうしません。

于 2013-04-10T15:44:12.820 に答える
1

数ヶ月前の私の質問とかなり似ています...

専用の主キー フィールドが必要ですか?

最終的に自動インクリメント PK を使用しました。

于 2009-02-26T14:09:30.463 に答える
0

すべての製品に SKU があり、SKU が各製品に固有のものである場合、それを主キーとして使用したくない理由がわかりません。

于 2009-02-26T13:06:05.827 に答える
0

アルファを取り除く SKUのハッシュをいつでも取得できます。可能性のある衝突 (非常にまれなはずです) をコーディングする必要があり、これは複雑さを増します。

ハッシュを使用して主キーを入力し、初期インポートを簡単にしますが、dB で使用する場合は、常に乱数であるかのように扱います。そうすれば、主キーはその意味を失い (自動インクリメント キーのすべての利点を持ち)、将来の柔軟性が確保されます。

于 2009-02-26T13:20:35.277 に答える