大都市圏を表す比較的少数のデータベース オブジェクトに対して、人間が判読できる主キーを使用できるかどうかを知りたいです。
たとえば、ワシントン DC の大都市圏の pk として「washington_dc」を使用したり、ニューヨーク市の都市圏の「nyc」を使用したりします。
大量のオブジェクトがこれらの大都市圏のオブジェクトに外部キー化されるため、データベース レコードを参照するだけで、個人または企業がどこにあるかを判断できるようにしたいと考えています。
これは良い慣行に対する重大な犯罪である可能性があると私の腸が教えてくれるので、私はただ心配しています.
それで、私はこの種のことを「許可」されていますか？
ありがとう！
それはすべてアプリケーションに依存します。自然な主キーは、人間が判読可能であり、エンド ユーザーにデータを表示するときに結合を必要としないため、表面的には非常に理にかなっています。
ただし、自然主キーはスラゲート主キーよりも大きくなる傾向がありINT(または. BIGINTあなたの例を挙げると、都市の名前が変わることは、それほど珍しいことではありません。都市の名前が変更されると、外部キーとして のすべてのインスタンスに触れる必要がある更新、cityまたは現実を反映しなくなった主キー (「データはレニングラードを示していますが、実際にはサンクトペテルブルクです。」 )
要するに、自然主キーは次のようになります。
＃1と＃2が＃3によって十分に打ち消されるかどうかは、構築しているものとその用途によって異なります.
この質問だと思います
あなたがしているかもしれないトレードオフの本当に良い概観を与えます。与えられた答えは正しいと思いますが、その簡潔さは、あなたが自分にとって正しいことを理解するために実際にやらなければならないいくつかの重要な考えを裏切っています。
（その回答から）主キーを検討するための基準は次のとおりです。
- 独自性
- 還元不可能性（キーのサブセットがテーブル内の行を一意に識別しない）
- シンプルさ（リレーショナル表現と操作をよりシンプルにするため）
- 安定性（頻繁に変更しないでください）
- 親しみやすさ（ユーザーにとって意味のある）
価値があるのは、主キーとして文字列を選択することでスケーリングに問題が発生した回数は、自動インクリメントキーを使用した冗長データに問題が発生した回数とほぼ同じです。自動インクリメントキーで発生する問題は、通常はすぐには表示されないため、私の意見ではさらに悪化します。
主キーは一意で不変でなければなりません。これらの両方の要件を満たす限り、人間が判読できる文字列を PK として使用できます。
あなたが与えた例では、都市が名前を変更しないことを考えると、それは問題ないように聞こえます（そして、まれに変更する場合は、十分な努力でPK値を変更できます）。
文字列の代わりに数値の PK を使用する主な理由の 1 つはパフォーマンスです (もう 1 つは、自動的に増加する ID を利用するためです。「 」を参照してくださいIDENTITY)。テキスト PK で 1 秒あたり 100 を超えるクエリが予想される場合は、intorbigintを PK タイプとして使用することにします。データベースのサイズと複雑さがそのレベルに達すると、SSMS を使用してテーブル データを直接編集するのをやめ、独自のツールを使用する傾向があります。これはおそらく JOIN を実行するため、都市の数値 PK と同じ結果セットで都市名を取得します。 .
あなたは許可されています。
通常、これはベスト プラクティスではありません。
数値 - 自動増分キーが優先されます。それらは簡単に維持され、ユーザーが新しい文字列をキーとして考える必要がない入力フォームやその他のインターフェースのコーディングを可能にします...
想像してみてください。ワシントン、またはwashton_dcまたはdcまたはwashtondc..などです。