SQL主キー：整数とvarchar
私が作業しているチームは、varchar主キーを持つテーブルを作成することにしました。このテーブルは、この主キーの別のテーブルによって参照されます。
私は大学で学んだことに従って、整数の主キーを作成する習慣があります。整数の主キーを使用するとパフォーマンスが向上することを読みました。
問題は、整数主キーを作成する他の理由がわからないことです。ヒントはありますか？
主キーは行のIDを表すことになっており、時間の経過とともに変化することはありません。
Varcharは、エンティティの名前、メールアドレス、シリアル番号など、何らかの自然なキーであると想定しています。自然なキーを使用する場合、次のような理由でキーを変更する必要がある場合があります。
- データが誤って入力されたため、修正する必要があります。
- ユーザーが名前またはメールアドレスを変更します。
- 経営者は突然、すべての顧客参照番号を完全に非論理的な理由で別の形式に変更する必要があると判断しましたが、問題の原因を説明した後でも変更を行うことを主張します。
- 国や州でさえ、その名前の綴りを変更することを決定するかもしれません-非常にありそうもないが、不可能ではありません。
代理キーを使用することにより、主キーを変更しなければならないことによる問題を回避できます。
VARCHAR対INTはあまり語りません。重要なのはアクセスパターンです。
絶対的に言えば、幅の広いキーは常に幅の狭いキーよりも悪くなります。タイプは絶対に重要ではなく、重要な幅です。しかし、INTと比較した場合、狭さでINTを打ち負かすことのできる型はほとんどないため、通常、INTは幅が4バイトしかないという事実だけでその引数に勝ちます。
しかし、really問題はclusteredキーの選択です。多くの場合、主キーと混同されますが、この2つは異なる概念を表しており、重複する必要はありませんnot。より詳細な議論 varcharまたはintの主キーを使用してテーブルを設計する必要がありますか？ クラスター化キーの選択は、テーブル設計で最も重要な決定であり、 INT identity(1,1)は、人が犯す最大の間違いかもしれません。アクセスパターンの問題の出番は次のとおりです。
- テーブルで最も頻繁に尋問されるものは何ですか？
- どの列が投影されますか？
- どの述語が適用されますか？
- どの範囲が検索されますか？
- どの結合が実行されますか？
- どのような集約が発生しますか？
- データはどのようにテーブルに挿入されますか？
- テーブル内のデータはどのように更新されますか？
- 古いデータはどのようにしてテーブルから削除されますか？
- 非クラスター化インデックスはいくつ存在しますか？
- nCインデックス（キーまたはリーフ）に含まれる列はどのくらいの頻度で更新されますか？
全体的に、INT IDENTITYクラスター化キーを使用することで台無しになる可能性のある多くのアクセスパターンがあります。クッキーカッターソリューションを適用するためにジャンプする前に、おそらく少し分析が必要です...
より一般的なガイドライン：
主キーはストレージ設計の問題ではなく、modelingの問題であり、完全にドメイン駆動であるため、主キーの設計ガイドラインはありません。
整数の主キーを作成する習慣があるため、少しがっかりしました（大学で教師が私に言ったことに従います）。整数主キーを使用したパフォーマンスブーストに関する多くのドキュメントを読みました。
これには用語があります： 確認バイアス ：
「確認的バイアスまたはマイサイドバイアスとも呼ばれます」は、人々が自分の先入観や仮説を、真実かどうかに関係なく確認する情報を好む傾向があります。メモリからの情報。」
もちろん、あなたの最初の反応は、「しかしそれは真実ではありません！」と言うことです。うん、あなたは「あなたが偏っているので、あなたは言うだろう;）[頬にしっかりと埋め込まれた舌]
ここに古典的な例があります。あなたはあなたの動物学の教授から、すべての白鳥は白であり、あなたとあなたの友人が出会った白鳥はすべて白だと言われたとしましょう。後年、同僚が、おそらくブラックスワンのような生き物がいるという意見を表明したとしましょう。何？！それはあなたが教えられたことではありません。あなたの世界は揺らいでいます！あなたはすぐに外に出て白鳥調査を行い、1,000羽の白鳥とゼロ羽の白鳥を数えます。証明！あなたが10,000匹の白鳥を見つけたなら、「すべての白鳥は白い」という仮説は10倍真実ですよね？
別のアプローチは、現時点では白鳥を忘れて、黒鳥を探してみることです。晴れた日で海辺で休暇を取るのかもしれない Dawlish ？
私は本当に無礼に聞こえるつもりはありません。あなたはあなたが言われたことについて多くを読むことを認めます、そしてそれは本当に私の尊敬を獲得します。そこで、ここに課題があります。整数列をテーブルに追加する必要がない場合を見つけてください。
ヒントとネタバレは次のとおりです。他のテーブルから参照されていないテーブル。単一列の「すべてのキー」ルックアップテーブル。あまり照会されない「小さな」テーブル:)
調査したいその他の関連トピックを次に示します。
「主キー」の「主キー」という言葉には多くの意味がありますか、それとも特定のテーブルのすべてのキーが同じですか？
「良い」キーの品質とは何ですか？ （たとえば、キーの値は不変である必要がありますか、安定性は「十分」ですか？）
整数列は、人工的なキー（利用可能な自然キーが「十分」ではないためperhpas）または代理キー（おそらく「良い」自然キーのパフォーマンスを向上させるため）としてテーブルに追加されますか？
サロゲートキーがパフォーマンスの理由でテーブルに追加される場合、これは実際に測定された効果のためですか、それとも単に知覚された効果（つまり、時期尚早な最適化）のためですか？
代理キーは論理ビジネスモデルに表示されるべきですか、それとも実装専用ですか？
毎回脳に関与することなく、常に何かを行うこと（たとえば、整数列をテーブルに追加すること）をお勧めしますか？ ;）
[免責事項：私は自然の主要な擁護者であり、代理人を避けます。私にとっては、非正規化のようなものです。通常、パフォーマンスの問題（具体的かつ実証可能）のために必要な場合にのみ行います。障害は他の場所にあります（お粗末なSQL製品バージョン、現時点では修正できない論理設計上の欠陥など） ）。代理は論理ビジネスモデルに表示されるべきではありません。人工的な識別子が必要な場合があり、論理的なビジネスモデルを公開することさえあります。]