【DB設計】ユニークと思いがちだけどユニークじゃないかもしれないもの

はじめに SQLアンチパターンの「IDリクワイアド」の章を読んだ後、私は疑似キー警察をしていました。 具体的には、プロジェクト内のDB設計で自然キーを使えそうなのに疑似キーを使っている箇所がないかを探して直そうとしていました。 ただ、本当に主キーとして自然キーを使用してよいか迷うことがありました。 それは自然キーだと思っていた列が、ビジネスの変化や実務上の実態によってユニーク性を保証しないことがあるからです。 また、とあるカンファレンスでt-wadaさんにデータモデリングの重要性について教えていただいたことが、この記事を書くきっかけになりました。 質問に対して丁寧に回答してくださり、ありがとうございました。 この記事の簡潔なまとめとしては、 疑似キー警察をしていた私が、取り締まるのに慎重になった。 なぜなら、ユニークだと思いがちだけどユニークじゃないものがあると知ったから。 というものです

[beejaga]

そういえば、新人の頃のJANコードやISBNの杜撰な運用を知った時の衝撃で、システム外部で定義されるIDはすべて信用せず擬似キー使うようになった

[kmaebashi]

ISBN重複なんかはさすがに罠だけど、社員コードで社員が一意に決まるかどうかなんてのは仕様の話で、もしそこが崩れるのならユーザマスタにサロゲートキーを振ってたって解決にはならないのでは。

[hogetax]

メールアドレスは退会/復帰処理をどう行うかも含めていつも悩む。ユーザに決めてもらうのも難しいし統一見解/標準設計が欲しいw

[frkw2004]

だから年月日をキーに含める設計があるのでは。

[revert]

社員コードも出向者がいる会社との合併が起きると同一性を簡単には担保できないのでね（一敗

[Kil]

新鮮な気持ちで読んだのに、在り来りな話だった。この内容が全然ユニークじゃなかった。

[prograti]

本店も支店も同じ法人番号だから、契約単位が支店単位になることを想定してないとユニーク制約違反になったりする

[kagehiens]

ある程度の経験を積むとDBエンジニアに必要なのは生物学者にも似た環境の観察習慣である、と気づく奴。

[otihateten3510]

長門「ユニーク」

[Fluss_kawa]

ISBN重複問題は結構昔から言われてた気がする。MACアドレスも規格上はユニークじゃなかったっけ？（記憶が曖昧）

[kamayan1980]

ISBNもそうだしJANもパッケどころか、原材料や中身が変わっても使い回しだったりするので信用ならない。

[ch1248]

よくあるやつ。

[uunfo]

抹消後や退会後の再登録だってあるので、重複しないと決めつけるのは危険

[kzmts]

ISBN以外のものはユニークとは限らない(再利用の可能性あり)と認識していたので納得の記事。/ISBNは自主的な取り込みで出版社側で運用を決めることができるとは知らなかった。

[NetPenguin]

以前だとこういう記事を読んで、なるほど〜とか思ったりして、自分の糧にしていたのだけど、最近だとこの手の知識もLLMに代替されていってしまうのかなと考えてしまい、ちゃんと読めなくなってきてしまった……

[Futaro99]

おちおちユニーク制約すらつけられないじゃん

[yamiyami27]

メールアドレスはあるある。社用携帯がiPhoneだから携帯管理する部署は割を食っている。かわいそう。

[mkusaka]

ISBN13桁やメール・電話・社員番号も状況次第で非ユニークになり得るとDB設計で警告する。

[nguyen-oi]

自然キー絶対許さないマンが一周回ってサロゲートキーの慈悲深さに気づくまでの記録。ISBN重複とか地獄すぎるな