さった6月28日に超高速開発コミュニティ&IT勉強宴会共催で開催された件名の勉強会の報告です。
https://benkyoenkai.connpass.com/event/58333/
すでにいくつものブログがアップされています。私が教えてもらったページを紹介します。
たなかこういちの開発ノート - サロゲート単独主キー vs 複合主キーの話、予習編
http://tanakakoichi9230.hatenablog.com/entry/2491274126
たなかこういちの開発ノート - サロゲート単独主キー vs 複合主キーの話、復習編
http://tanakakoichi9230.hatenablog.com/entry/0631240514
システム開発の本質とは～単独主キー主義 VS 複合主キー許容派～
https://www.talon.jp/column/past_20170630.html
ＩＴ勉強宴会blog 「単独主キー主義」の是非を問う＜超高速開発コミュニティ＆第57回IT勉強宴会in東京＞ (2017.7.3 追記)
http://blog.benkyoenkai.org/2017/07/57itin_2.html
上記と重複しないように私なりの知見を整理します。
今の時代、まだこんなことを議論しているの？
そうですよね。私もここまで盛り上がるとは思いませんでした。当日に参加された30名弱の皆さんは、現場でDB設計のエキスパートとして活躍されている方も多く、いまさらこんなネタをと、お叱りを頂戴する場面も想定していたのですが… まったくそんなことはありませんでした。
ではセミナータイトルにあるように、参加者が皆、複合主キー万歳かというとそんなこともなく、論理設計の段階では複合主キーであっても、実装の段階で（物理設計として）サロゲートキーを適用することはありうる、という声が多く上がりました。
問題はここからです。なぜサロゲートキーを適用するのか。そこに必然性があるのか。それとも実装環境が単独主キーしか対応していないため、そうせざるをえないのか。後者はある種の制約なので議論の対象とはしませんでした。白熱したのは前者の方です。
テーブル定義をドキュメントとみなすか、単なる入れ物とみなすか。
ここからは私の理解です。論理設計で複合主キーを見つけたなら、それをそのまま物理設計にも適用すればいいではないか派（以下、複合主キー派と呼びます）は、テーブル定義を一瞥することでシステムの概要がほぼ理解できる、ことを大きなメリットとしてあげています。テーブル定義には、そのシステムの目的、思想、制約が語られているということで、それ自体が貴重な情報源（ドキュメント）です。仮に主キーの変更があった場合でも、テーブル定義から影響範囲を知ることができるので、改変そのものは可能です。デメリットはデータの洗い替えが大変なことです。
一方で物理設計ではサロゲートキーを積極的に使いたい派（以下、単独主キー主義派と呼びます）は、テーブルは単なるデータストア以上の役割をもたさず、それよりも将来のデータ構造の改変リスクを抑えることを重視します。実際、当日の会では「まさか変わると思っていなかった主キーの変更があった」という体験談も盛り上がり、だからサロゲートキーを使っておけとあれほど… と思わせるすごみもありました。デメリットは本来、誤ったデータを登録させないためのさまざまな仕組み（値の組み合わせのユニーク性の保証や、更新不可制約）をアプリケーション側で面倒みることです。テーブル定義であればDBが保証していたことを、アプリケーション側で保証することになります。
上で紹介したブログで、これは静的型付け言語と動的型付け言語の比較に近いという知見があがっていましたが、なるほどと思いました。
なぜサロゲートキーか、という背景に迫る
積極的にサロゲートキーを適用すればテーブル構成は柔軟になる、というのは、正確には「（一部の）業務要件の仕様をユーザが決められない、もしくは決めた後で変更される」という経験を多くの技術者が体験していることの裏返しでもあります。そして主キーの変更は手戻りの影響が大きいため、それを最小化するために複合主キーは使わないという判断は理解できます。もちろん論理設計の段階で、これは複合主キーだろうと判断していれば、サロゲートキーを適用したタイミングでもテーブル定義に複合ユニーク制約を指定し、かつアプリケーションでこれらの項目は更新不可となるような実装をすることで、少なくともデータがおかしくなるという問題を回避できます。「メリットもデメリットも勘案して、あえてサロゲートキーを使っているのだ」ということです。
しかし多くの方の体験談を伺っている中で、次のような懸念を感じてきました。
- そもそも論理設計の段階で、実はキー設計を重視していない。キーの設計は業務の理解が必須だが、それをさりげなく避けることで上流設計を終えてしまう。後工程で「このデータの組み合わせが存在しているのはおかしい」などの問題が生じた場合、プログラムを修正し、テストを追加することで乗り切る。いわゆるトラブル駆動による修正だが、これはそもそも業務アプリケーション開発のスタイルとしてどうなのか。もはやエンジニアリングと呼べるものではないのではないか。（これが座長の渡辺さんがもっとも懸念していたことと思います。）
- ERPの多くが、そもそもサロゲートキーでつくられている。理由は「幅広いお客様に対応するため」。その方針は否定しないが、それを理解して導入しているITコンサルタントや、ユーザー企業はどのくらいいらっしゃるのかが気になった。
- 少なくとも論理設計の段階で、適切な主キーの設計を行うという手法自体が、業務経験者から若手エンジニアに伝えきれていない。複合主キーの概念を知っていて、あえてサロゲートキーを適用する（そのタイミングで適切な代替テクニックを実装する）ことと、複合主キーを知らずにサロゲートキーを使うのが一般的と思って設計することは異なる。後者は「カットオーバー後、不適切なデータが存在している」という問題自体に、おそらく気づかない。気づかないまま新しいシステム開発を行うため、問題を共有することもできない。
サロゲートキー利用が「苦渋の決断」であるならば、超高速開発ツールはその状況を変えられるのではないか
出席者の少なくない方々は、論理設計の重要性や複合主キーのメリットを理解しているが、お客様による仕様の確定が進まないことや、要件の度重なる変更を勘案すると、サロゲートキーの導入は現実的である、という判断をされているようでした。
しかしその前提は、主キーの変更による手戻りが大きいこと、さらにいえば「どこに影響があるかさえ、わからないほどの巨大なシステム」を扱うことの困難さが生んだことでもあります。
超高速開発ツールの登場は、この前提に一石を投じます。主キーの変更による影響度を判断し、ほぼ自動でプログラムの改変作業を行うためです。もちろん、運用後の改修であればデータの洗い替えという面倒な作業は残ります。それが大変なんだよ、という声は十分わかります。一方で、適切なキーの設計はシステム全体の見通しをよくするため、少人数開発が行いやすくなります。おかしなデータは混ざっていないという「保証」ができます。私の経験では、この保証という概念がとても重要です。テスト工数も減らせますし、データの利活用（再利用）を促進します。
余談ですが世の中のビッグデータ活用は最初に「自社のデータがあまりにも汚い」ことに驚き、その正規化に多大なコストがかかるという話をよく耳にします。これなどは問題の先送りがあとで追加コストとして跳ね返ってくる典型的な事例です。事前に手間をかけるが後は楽になる（活用しやすい）世界を是として、その実現のために複合主キーという武器が使えるなら使った方がいい、という視点が増えてもよいと思います。そのためには手戻りを吸収する開発環境が必須であり、それが超高速開発ツールの役割の一つといえます。
まとめます。
まだそんなことを議論しているの？ も、追求すれば見えてくることはいろいろある、ということを学べた勉強会でした。業務アプリケーション開発は奥が深いですし、改善のためにやるべきことはまだまだあると実感しました。
（いや、地味すぎるだろ、この話は、と突っ込まれるとそうなんですが、当たり前と思っていた土台を見直すことは案外、面白いものです。）
