Living Dining and Blog

■サロゲートキーと情報の保護

複合主キーなんて使ってたら画面遷移のたびにいろんな項目をキーとして渡さなきゃいけなくなるから工数が増える。些細なことのように思われるかもしれないが、ページによって渡すパラメータが変わるってのはページ遷移ごとにキーがなにか考えなきゃいけないから無駄な思考コストが開発時・運用時ともにかかるわけ。コントローラ側も汚くなる。

TokuLog 改め Perl を極めて結婚するブログ - サロゲートキーを使わないという選択肢はない

Web アプリケーション開発の実績はありませんが、まさにその通りだと思います。思考コスト低減、分かりにくいですが、確実にあるでしょう。

また、サロゲートキーを使うべきである理由がもう一つあると思います。

例えばコード（ナチュラルキー）ベースで開発した既存システムを、そのまま Web に移行したい、なんていう場合を考えてみます。

そのシステムでは、各顧客ごとにデータを公開するとします。顧客は、内部的にコードで管理されますが、それは表立って問題にはならないでしょう。ところが稼動から数年経って問題が発生するかもしれません。

例えば A という顧客と取引があり、そのデータは顧客 A に公開されます。その後数年が経ち、新たに B という顧客と取引を行うことになりました。顧客コードの桁数は稼動直後こそ余裕があったものの、現在ではあまり空きがありません。そこで、もう取引のなくなった顧客 A を削除し、同じコードを使うことにしました。その後、顧客 B から覚えのない取引データが見れるとの報告が届いたのです…。

もちろんこの例え話は突っ込みどころがたくさんありますが、古い業務システムを何度か扱った経験からすると、まんざらありえない話ではありません。リレーションも張らずに、とても単純にコードだけで管理しているシステムはいたるところにあるのです。

以上を踏まえると、ユーザの手で人為的に変更のできないサロゲートキーは、情報の保護という面でも意味を持ってきます。

余談ですが、コードベースの設計やプログラミングに慣れすぎて、サロゲートキーの便利さ、手軽さをなかなか感じることが出来ていない人が周囲に結構います。先入観というものはなかなか難しい。

Permalink | コメント(0) | トラックバック(0)