web-dev-qa-db-ja.com

顧客コードを主キーとして使用することの長所と短所は何ですか？

私は私の営業チームの1つのデータベースを設計しています。現在、目標は顧客とその住所のマスターリストを取得することですが、DBは最終的に他の顧客データを追跡するために拡張されます。したがって、今は顧客の表に取り組んでいますが、これが現在の期待を超える場合に備えて、適切な正規化と効率のガイドラインに従っていることを確認したいと思います。

現在、顧客数は約3,000人です。そのため、お客様を識別するために使用するお客様コードがあります。それぞれ最大20文字で、英数字で、顧客ごとに常に一意になります（Foo、Inc.にはFOOINCのカストコードがあり、25のサブアカウントがある場合がありますが、FOOINCマスターエンティティは1つしかありません。 Foo Technologies Incと呼ばれる別の会社とビジネスを行ったことがあるので、FOOTECHなどの新しいコードを作成します。

私はDBAではありませんが、過去にいくつかのDBを設計し、SQL IDフィールドをPKとして伝統的に使用しています。この場合、私は顧客コードの使用を考えていました。これを行うことの長所/短所は何ですか？一方では、私が持っている場合、一意の識別子をPKとして使用するのが理にかなっています。もう1つは、文字列PKがint PKよりも遅いことを知っています。このデータベースは確実に大きくなりますが、数百万行になることはありません。 3,000人の顧客は7年以上のビジネスを持っているので、数万行になるまでにはかなり時間がかかります。

私はこの質問を調査しましたが、通常は「データに依存します」という議論で終わります。そのため、教えてください...この状況で、テーブルを計画するときに何を考慮しますか？ PKには何を使用しますか？とにかくそこに自動インクリメントINTを固定する利点はありますか？レコードのインデックス作成と挿入に関する問題はありますか？

ちなみに、テーブルレイアウトには次のものが必要です。

-CustomerCode(nvarchar(20))
-CustomerName(nvarchar(50))
-Address1(nvarchar(50))
-Address2(nvarchar(50)) - nullable
-Address3(nvarchar(50)) - nullable
-ZipCode (nvarchar(9))

おまけの質問-3NFを使い続け、ZipCodeをPKとして都市、州を保持する別のテーブルを作成し、顧客のテーブルとの関係を作成する価値はありますか？または、いくつかの結合を回避するために、3NFを心配せずに都市/州を顧客テーブルに保持しますか？

助けてくれてありがとう！他に詳細が必要な場合はお知らせください。

sql-serverdatabase-designprimary-keynormalization
5
Jim

長所-それは自然な鍵であり、それは理にかなっており、おそらく検索されると思いますか？

短所-デフォルトの動作（完全に変更可能）では、主キーがクラスター化インデックスになります。英数字は、ID列のように増え続ける値に設定されていないため、挿入によってページ分割が発生する可能性があるため、最適な候補にはなりません。 Int ID列は、文字データ（Unicodeの場合は40+バイト）と比較して、スペース（4バイト）が少なくなります。クラスタ化されたキーはそれらの一部であるため、これにより他のインデックスが大きくなります。顧客を識別して顧客コードを作成する方法を変更した場合、これはすべて失敗します。サロゲートを使用すると、これらのタイプの変更から隔離されます。

この状況では、挿入パフォーマンスを最適化し、クラスター化キーと主キーではなく、ID列を使用する傾向があります。整数のクラスター化インデックスが本当に好きです。 （私はあなたの質問がクラスタ化インデックスについてではなく、主キーについてだったことを知っています...クラスタ化インデックスとして他の列を選択してこれを主キーにすることもできます、これに一意の制約を設定して処理することもできます自然キーとして使用しますが、主キーにはしません）。

少なくとも、これに一意の制約を付けてインデックスを付け、自然キーのように扱います。本当にそれを主キーにする必要があるかどうかはわかりません。

Kimberly Trippは信頼できるリソースであり、ブログで主キーと（さらに言えば）クラスター化キーについて多くのことを語っています https://www.sqlskills.com/blogs/kimberly/guids-as-primary- keys-andor-the-clustering-key /

これはすべて私の意見です-YMMV。

3
Mike Walsh

あなたの値は良い主キーになりますが、くだらないクラスタリングキーになります。クラスタリングキーのID列をテーブルに配置して、大きな文字列を主キーとして使用できるようにします。これにより、キー値を主キーとして使用し、IDをクラスター化インデックスのベースとして使用できます。

3
mrdenny

お客様のFOO、Inc.が社名を変更するとどうなりますか？ "FOOINC"のすべてのインスタンスを別のものに変更する必要があります。それが主キーであり、外部キーへの参照を持つ他のテーブルがある場合、頭痛の種を自分で購入したことになります。

結論：それをしないでください。主キーはほとんど常に整数である必要があります-インデックス自体が純粋にコンピューターの使用のためである自動インクリメントされたIDフィールドのみであるため、問題ドメインに関連する固有の値はありません。

2
Michael Ross