複合主キーの扱い方

緊急開催：複合主キーは必須なのか？＜第55回IT勉強宴会Light＞ に参加しました（主催者まとめ）。

議論の発端は渡辺幸三さんの「単独主キー専用環境」と賢くつきあうためにという記事。

乱暴に説明すると「データベースではきちんと複合キーを使うべきだ。OOPだからといってカスケードキーでいい加減に作るから、あとでわからなくなって保守ができなくなるんだ。ばかやろう！」ということ。

ここにはいくつか議論をしないといけないことがあります。一部追記したスライドを元に説明しましょう（追記部分は灰色の小さい文字になっています）。

複合主キー from Makoto SAKAI

RDBだから複合キーを使わずにできてしまう

渡辺さんのブログを読んでいると、RDBなのになぜ複合キーを使わないのか、という気持ちが透けて見えます。でも、実は多機能なRDBだから複合キーを使わずにできてしまうのではないでしょうか？

複合主キーを持てないKVSや連想配列があります。これらを使うとき、シーケンスの管理が
難しいこともあり、「キー1＿キー2」のようにして開発しています。

このことから考えると、RDBなのに複合主キーを使わないのではなく、RDBだからサロゲートキーを作りやすいので、複合キーを使わない開発が簡単にできてしまうのだと思います。

つまり、単独主キーで開発を安易に行うことが問題です。

本来、複合主キーで表現されるデータをどう扱うかは、モデリングの問題ではなく実装の問題です。

複合主キーを使わないのは実装の都合なので、そこにある危険性を周知することが重要だと思います。

（もちろん、、モデリングしているのはあたり前としてです）

オブジェクト指向だから単一主キーとは限らない

渡辺さんのブログでは「OOP好きからは『テーブルに別途ユニーク制約を置くなり、クラスの中に制約のためのロジックを盛り込むなりすればよいだけではないか』と反論されそうだが、」と書かれていますが、それは時代に流されている人ではないでしょうか？

オブジェクト指向システム分析―上流CASEのためのモデル化手法には「オブジェクトのそれぞれのインスタンスを唯一に識別する1以上の属性の集まりは，そのオブジェクトに対する識別子です。」と複合主キーを認めています。

ソフトウェアを開発する場合、様々な視点で特徴や制約をモデリングしないとシステムの詳細は表現できないと思います。複雑な要素を如何に矛盾なく、いかにわかり易く統合していくかが設計者の腕の見せ所では無いでしょうか。

保守性の考慮

もちろん、実装の都合でモデルと異なる方法をとったり、モデル自体を実装に最適化することもあるでしょう。しかし、その場合は注意深く開発する必要があるでしょう。

渡辺さんのブログには「複合主キーを扱えない」という環境自体の特性ゆえの問題が書かれています。

• エンティティのまとまりやそれに適用される複雑な制約が、開発者自身によって見い出されない
• 使いづらく保守しにくい業務システム開発が生まれる
• 単独主キーだけを用いた設計スタイルに逃げ込んでも、問題が見えにくくなるだけで事態はさらに悪化する

つまり、きちんとモデリングされず、保守しにくいシステムが作られ、どんどん深みにはまってしまいます。

このように考えると、複合主キーを使ったモデルそのままに実装できるならDBを見ればわかるかも知れませんが、モデルと異なる実装ならモデルからどのように実装に持ち込んだかわかる様にしておかないといけないと思います（もちろん、モデリングしている前提です）。

おわりに

渡辺さんの主張をより単純化すると「バグを出すなバカやろう」だと思います。

なぜ、バグが出るか、それは「複合主キー環境でないから」ではないと思います。たぶん、複合主キーが使えても同じようなDB設計をするのではないでしょうか？

もし、きちんとモデリングができるなら、本来必要な制約を理解し、わかり易く制約を実装し、必要ならドキュメントも作成するでしょう。

「もともとDB設計というものは高度な専門職」とは思いません。もし、そうなら、ソフトウェア開発のインタフェース設計、システムチューニング、保守、運用、すべて高度な専門職です。

エンジニアリングは一定の努力で誰もが習得できる専門知識です。きちんと勉強して、危険性を理解すれば良いと思います。

問題はすでにできてしまったお客様のシステムをどうするかです。危険性を考慮せずに勝手な思い込みで作られたやっつけシステムは、問題が起きた際は大変だと思います。作り直したくても予算も期間も無いからです。

担当される方のために祈らずにおられません。

彼らをお赦しください。自分が何をしているのか知らないのです（ルカによる福音書/ 23章 34節、日本聖書協会）