単独主キーでもDB設計は楽にならない - 設計者の発言

我ながらしつこいが、どんな開発環境においても「id」のような単独主キーを用いる設計手法の危険性について、もう一度指摘したい。この手法を「単独主キー主義」と呼んでおくが、これに関して「複合主キーを用いると主キーが変化しやすいから」とか「単独主キーのほうが仕様変更に対応しやすい」といった擁護意見がある。それらの主張が無効であるばかりか有害でさえあることを説明しよう。 なお、私はこの議論で「だからナチュラルキーが正しい」と言おうとしているのではない。じっさいのところ私はナチュラルキーを主キーにすることに反対しているが、それは本稿の主張と矛盾しない（参考記事）。ここで私が言いたいのは、複合主キーを用いたオーソドックスな設計手法を身につけたうえで、利用する開発環境の制約にもとづいて慎重に正規化崩しできるようになろう、ということだ。 ■サンプルのデータ要件 複合主キーを要求するデータ要件として、前の記

[troter]

設計は楽にならないかもだけど複合主キーは業務キーになりがちでjoinに利用するカラムなのに洗い替えとか発生しがちで複数のテーブルの修正とか避けるためユニークキー＋単独主キー使いたい派。join条件落ちしにくいし

[okinaka]

主キーの問題よりずっと根深い設計上の問題はいくらでもあるのだけれど・・・。

[Error401]

複合主キーだと、Webアプリの作りが非常に辛いことになるという事情もあります･･･。

[Dai_Kamijo]

“単独主キーでもDB設計は楽にならない: 設計者の発言” — Hidenori Goto (@hidenorigoto) May 23, 2017 from Twitter https://twitter.com/Dai_Kamijo May 23, 2017 at 05:49PM via IFTTT

[yojik]

OOモデリングでは同値性の設計があるし、永続化時にユニークになる属性の組み合わせの検討をきちんとやる人は当然いるとは思う > 単独主キー主義にこだわれば、それ以外のユニーク制約を考慮する習慣が身につかない