Q&A
> 私はPKとしてint型のIDが欲しいのですが
どうしてですか？
識者の方々にお聞きしたいのですが以下のようなテーブルの時
ユーザCode PK varchar 例：M123456
ユーザ名 varchar 例：たろきち
〇〇
私はPKとしてint型のIDが欲しいのですが、このユーザコードをPKに充てる人を
よく見ます。
これはどういった思想なのでしょうか？？
理由は色々あるのですが、例えば全社で人員管理システムが刷新するときに、ユーザコードが変わる
そんな時に、ユーザコードでリレーションされた全データは変更しなければなりません。
しかしもしユーザコードを単なる属性と捉えIDをリレーションキー(PK)とするならそんな問題は起きえないです。
> 例えば全社で人員管理システムが刷新するときに、ユーザコードが変わる
変えるほうが悪い、もしくは変わりうるキーを使ってしまった設計が悪いです（この文字列キーは「内部的に振って、決して変わらない」ことを前提に考えていました）。
なるほどです、仰る通りその理屈はスッと腹落ちします。
回答6件
0
例えば全社で人員管理システムが刷新するときに、ユーザコードが変わる
そんな時に、ユーザコードでリレーションされた全データは変更しなければなりません。
しかしもしユーザコードを単なる属性と捉えIDをリレーションキー(PK)とするならそんな問題は起きえないです。
質問の内容は、primaryKeyとして、サロゲートキーを使わずにナチュラルキーを使う意図という事になりますが、「ユーザコードでリレーションされた全データは変更しなければなりません」については、連鎖更新の設定をすれば、自動で更新はされますので、ナチュラルキーを選択して必ずしも悪いという訳ではありません。
サロゲートキーを知っていて選択しない一番の理由は、サロゲートキーの生成ルールを組み込むのが面倒と感じた（手抜きとまでは言いませんが）からでは無いかと思います。
後は、外部参照で構成されるような場合に、ナチュラルキーであれば、元を辿る必要が無いというメリットは考えられますが。
投稿2021/11/08 08:54
編集2021/11/08 12:38
総合スコア25327
0
システムはいくつか触ってきましたが、
例えば、DBの容量を少しでも削減したいパターンがあります。
主キーとコードで列が2つになり片方にはPK片方にはユニークでインデックスも2つになる、
これをいくつものテーブルでやりたくないパターンです。
または、設計的にコードが変わることをあまり考慮しないパターンがあります。
何年、あるいは十数年使用してきた社員番号などをコードに使用して新たにシステムを建て付ける場合、社員番号体系の変更は今更影響が大きすぎるので、体系の変更が発生することはないだろうということにするパターンです。
投稿2021/11/08 05:20
総合スコア610
0
ユーザーコードが変更されない仕様であれば十分あり得ます。
もちろん、変更される仕様であっても、整合性が取れるように設計実装されていれば何の問題もありません。
投稿2021/11/08 04:53
総合スコア80875
ご回答ありがとうございます。
仰るように、絶対にID(int）でなければならないという訳ではないでしょうが、何かしらの不安があるにも関わらずそれを主キーに設定するのに、特別な理由？思想？があるのかなと
冒頭に書いてます。
>ユーザーコードが変更されない仕様であれば
それが不安かどうかは外部から見た私見でしかないので、理由は「そういう仕様」ということで良いと思います。
使わない情報をキーとして持っておいてもリソースの無駄ですので「必ずユーザーコードで一意となる」のなら、なんの不安もないかと。
もっと言えば、「おそらく」でしかないですが、teratailもユーザー名で一意です。理由はプロフィールページのURLがユーザー名だから。
リソースを意識した設計という理由が多いみたいですね、納得できました。
かどうかはプロジェクトの方針次第、要件次第ですね。
0
これはどういった思想なのでしょうか？？
主キーは一意でさえあれば、理論的には何でも構いません。整数でなく、128ビットのUUIDを主キーに振るような例も見かけます。
投稿2021/11/08 04:41
総合スコア146018
早速の返信ありがとうございます。
仰るように理論的には問題ないのですが、開発効率や拡張性を考えたときに後々大変だろうと想像するのです。
> 開発効率や拡張性を考えたときに後々大変だろうと想像するのです。
id列があることを前提としたフレームワークもありますので、そういったものとマッチしづらいのは間違いないです。
（とはいえ、そういうツール側からの制約がなければ、この手法も特段の問題はないかと思います）
例えば、回答者さまだと、主キーの割り当てはどうされますか？やはりユーザコードを主キーにしますか？
フレームワーク無しとした場合です。
補足に書いたように「外部的な都合であとから変わりうる」ものであれば、迷わずidを振ります。
（システム内で振る人工キーに数字を使うか文字列を使うか、の議論と捉えていましたので、変わりうるデータだとしたらまったく別問題です）
柔軟な思想を聞くため意図的にズラしていた部分はありますが、仰る通りですよね。
追加で質問させてくださいm(__)m
私は基本IDを振るのですが、もう一つの理由として【数字であるが故に、見た目にもNextDataの取得や、メソッドの引数としても取り扱いがしやすい】と思うのですが、それでもあえてユーザコードをPKとするとき、それはどんなメリットがあるでしょうか？
後学のために教えてください。
0
これはどういった思想なのでしょうか？？
ちょっとアンケートに近い質問だとは思うのですが、個人的な意見だけ記述しておきます。
ユニークなユーザCodeで管理されるテーブルを作成し、それ以外のものを管理したくない場合にそうします。データ量だけでなく、パフォーマンス的な視点(必ずユーザCodeでのインデックスが必要になる)からも、可能であれば余計なものを入れたいとは私は思いません。
逆に理由がコストに見合うと思えばサロゲートキーを使います。
投稿2021/11/09 07:26
退会済みユーザー
総合スコア0
0
外部キー制約のマスターとして使用する場合はユーザーテーブルならユーザーIDをPKにする意味がありますね。
PKはデータをユニークに掴むことはできてもid自体に意味を持たせないのが原則なのでリンクするIDとしては使えないので。
逆にユーザーIDが履歴を持つデータにする場合は、ユーザーID自体がユニークにならないため、別途PKを持つほうが効率的な場合もあります
投稿2021/11/08 06:13
総合スコア116724
あなたの回答
tips
プレビュー
