« DBMSの方言を開発基盤で吸収する | トップページ | 「強制されたサロゲートキー」の事例を眺める »

2012.01.28

サロゲートキーは強制されるべきものではない

 複合主キーに代えてサロゲートキー(単独主キーの代替キー)を導入すべきかどうか。それはDB設計上の重要な判断事項である。なにしろレコードのアイデンティティである主キーの設定にかかわる問題だ。さまざまなメリットやデメリットを考慮してそれは判断される。その結果、サロゲートキーを導入することもあるし、しないこともある。

 ところが、サロゲートキーを強制する(あるいはサロゲートキーを導入しないと開発しにくい)開発基盤がいくつか存在する。具体的には、全テーブルの識別子が"ID"等のフィールド名を持つ単独主キーであることが求められたりする。私に言わせれば、そういう開発基盤は「大盛を強制する牛丼屋」である。メニューにあるはずの「並」を頼むと、あれこれイヤガラセをされる牛丼屋。

 この問題に関連して、「サロゲートキーを使わなかったから、ひどい目にあった」という開発者の声を聞いたことがあるかもしれない。心配はいらない。その証言は言葉足らずで、正確には「サロゲートキーを使わなかったから」ではなく「ナチュラルキーを主キーにしたから」である。ナチュラルキーと複合主キーとが相互に無関係である(直交している)ことは「ナチュラルキーを主キーにしてはいけない」で説明したとおりだ。「ナチュラルキーではない複合主キー」はごくありきたりなデータ要件で、それを開発基盤がことさら拒否することに何の意義もない。

 「大盛を強制する牛丼屋」があるとしたら、その理由は「客単価を増やすため」であろう。「サロゲートキーを強制する開発基盤」があるとしたら、それにも理由があるはずだ。いったい何なのだろう。

 まず想像できるのは「そうすれば開発基盤の内部処理が単純になるから」というものだ。それはそうだろうが、基盤の開発者がこれを正直に語るとは思えない。代わりに「複合主キーのような複雑なデータ構造などを許せば、システムが複雑になる。それを抑えるためにサロゲートキーを強制することには合理性がある」と説明するかもしれない。確かにそうすることでテーブル構造の面でシステムは単純に見えるだろうし、「開発基盤の開発者」としても楽が出来るだろう。しかし、話はそれでは済まない。

 データベースシステムには「複雑さの保存則」のようなものがある。「データ構造の複雑さ」と「データ処理の複雑さ」の総量は一定である。つまり、同一のデータ要件において、データ構造を単純化すればデータ処理が複雑化する。たとえば私の言う「森羅万象テーブル」は、たったひとつのテーブルでシステムの全データを保持しようとするチャレンジングな設計スタイルなのだが、これほど「ベストっぽいシンプル」なDB構造はない。しかし、そのデータ処理様式の複雑さは想像に余りある(じっさい、ここらへんは経験者にしかわかってもらえないのが悲しい)。

 データ処理様式に関する情報量の多さこそが保守性悪化の主要因なので、データ構造を意図的に単純化する設計方針は的外れだ。言うまでもなくデータ構造を意図的に複雑にすることも間違いだが、データ構造は宣言的に扱えるものであるゆえに、複雑にできる余地が大きい。少なくとも「ナチュラルキーではない複合主キー」程度の複雑(?)なデータ要件は、そのままの形で受け入れられるようでなければならない。

 したがって、システムのDB設計の良否は次のように評価できる。データ要件が素直に読み取れるようであれば、それは良いDB設計である。いっぽう、見ただけではデータ要件が判然とせず、処理様式を調べないとわからないようであれば、それは劣ったDB設計である。DB構造が本来担うべき「意味」を、プログラムコードが代わって抱え込んでいるということだからだ。そのようなアプリはコード量が増えるため、その可読性に関わらず保守性に劣る。

 サロゲートキーを強制する開発基盤が生み出される2つ目の理由として「WEBアプリの開発環境だから」というものがあるかもしれない。これはむしろ下手な言い訳というべきだ。WEBアプリであるかどうかと「複雑」なデータベース構造を扱うかどうかとは別問題だからだ。じっさい、複合主キーをふつうに扱えるWEBアプリの開発環境はふつうに存在する。

 3つ目の理由。開発基盤のDB処理まわりの設計が、オブジェクト指向の発想に変に引きずられたためではないか。RDBは「関数従属性」や「ドメイン制約」にもとづいて切り出されるデータ構造を扱うしくみである。テーブルレコードを特定するための手がかり(キー)が「オブジェクトID」に似た単独主キーで済むという発想では、z=F(x,y)のようなありきたりな関数従属性さえ手に余る。オブジェクト指向(OO)とデータ中心アプローチ(DOA,DCA)はそれぞれ独自に発展したものだ。開発基盤の開発者なら、双方の素養を適宜使い分けられるようでありたい。

 要は、個別アプリの設計者がサロゲートキーを好もうが好むまいが、使いやすく保守性の高い多様なシステムを生み出せたらいいだけの話ではある。それゆえにこそ、サロゲートキーの導入は設計者の判断にまかされるべきだ。サロゲートキーでもオーケー、複合主キーのままでもオーケー。そんな開発基盤であってほしい。――って、なんとつつましい願いだろう。結婚相手はお箸くらい正しく持てる人であってほしい、みたいな。

|

« DBMSの方言を開発基盤で吸収する | トップページ | 「強制されたサロゲートキー」の事例を眺める »

コメント

御意

投稿: TOM | 2016.07.06 17:13

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: サロゲートキーは強制されるべきものではない:

« DBMSの方言を開発基盤で吸収する | トップページ | 「強制されたサロゲートキー」の事例を眺める »