がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

論理削除とサロゲートキー

いや端的には「どっちも原則的にはいらん」っていう立ち位置なのですが。
その辺も含めて、一旦「現時点での」おいちゃんのスタンスを、メモ程度に。

論理削除

最近見ていると割と「いらん!」な方向に向いている記事が多いのであんまり気にならないっちゃぁ気にならないのですが。
おいちゃんの現在のスタンスは「原則、物理削除」。
ここからいくつかお話が散らかるのですが…
まず第一に考えるべきなのは


・その削除は、削除ですか? stateの変動ですか?


という疑問。
この辺りは
「DELETE_FLAG を付ける前に確認したいこと。( http://qiita.com/Jxck_/items/156d0a231c6968f2a474 )あたりが大変に興味深いのでご一読のほどを。


結論として。
基本的には、おいちゃんは「異なるstateなら異なるテーブルに」なので、DELETE+INSERTで「データが入ってるテーブルを切り替える」ほうが多いのですが。
「諸々の制約や予算コストの類の消耗」が受け入れられる範囲における「論理削除」であれば、状況によっては(例:削除後もkeyの重複を避けたい)、可能性として考慮しうる選択肢だと思います。
一方で「とりあえず全てのテーブルにdelete_flag」というのは、何一つ受け入れられない主張だなぁ、と、おいちゃんは感じるわけなのですね。


あと、stateの話でもう一つ「虫唾が走る」のが「1テーブルに複数のstateカラムがある」設計。
例えば1stateが2つの状態のスイッチ(いわゆるbooleanな値)だとしても。stateのカラムが6つあれば、実に32パターンのstateが存在しうる状態になるのですよ?
そんなもん、誰がテストしてられっかい(笑


上述の矜持類似で「データの削除は非推奨( http://www.infoq.com/jp/news/2009/09/Do-Not-Delete-Data )」なんてのもあります。こちらも一読推奨。
ここで「単純にinsert時の入力ミスまでロギング的に情報を残すのかね?」という疑問がないではないのですが、まぁ「どこまでがミスによる削除で、どこからがstateを残すべき状態の積み重ねなのか」を議論して議論のテーブルが混乱した挙句にマシンガンを打ち込むくらいなら、一律「削除しねぇ」って選択肢も、まぁ、なくもないのかなぁ、と。


ただ一応、上述に反論を申し述べますと。
おいちゃんのバトルエリアの一つであるソシャゲとかの案件ですと、まず構成がMySQLなので「器用なパーティショニングとか出来ねぇ!」ってのがありまして。
次に「ギリギリまでチューニングしたい」っていう割と切実な状況があるので。
結果的に「いらん(コールド)データを残せる余地なんざあらしませんがな」状態になることも多いので、その場合、あんまり選択の余地はありませぬ。


対運用(より正確には対クレーム)用には、別途、(テキストが望ましいけどまぁ別に切り出すんならDBでも)ログを作っておきませう。


ってなわけで、おいちゃんは「物理削除」が基本になる事が多いです。

サロゲートキー

もうちょっとかしましい感じかなぁ、と。
ネットでみても、現時点で結構「どっちも」な論点があちこち。


まず初めに見ておきたいのが、こちら。
サロゲートキー vs 複合キー」という間違った対立( http://osa.hatenablog.com/entry/2014/03/19/180330 )。
上述にあるとおり、比較軸が
・自然キー vs 代替キー(おいちゃんは人工キーっていうけど)
・単一キー vs 複合キー
になります(「主キー vs 代理キー」に起因する言い争いは、おいちゃんの観測範囲内だとあんまりないので、一旦省略)。


おいちゃんの基本スタンスは「自然キー(ナチュラルキー)万歳。複合キーもありありで」一派。


まず「単一キー」な状態で「何故に人工キー(サロゲートキー)」をふらにゃならんのか。
"特に問題がない限り"自然キーを素直に使うのが一番素直です。
この辺、奥野さんのスタンスと一緒( http://nippondanji.blogspot.jp/2013/12/blog-post_4.html )。
ここでポイント"特に問題ない限り"。


サロゲートキーを持ち上げる記事の幾つかを見ると、割と典型的なのが
・商品IDとか、年度によって指し示す商品が変わるんですものkeyになんて怖くて出来ません!!
って類の主張。
一方で「それ、そもそも設計ミス」ってツッコミにはなるんだけど、「設計ミスは仕様なので設計ミスではないからこの設計で"正しく"動くように」とかいう上意下達下克上禁止があったりするので、そーゆー時は「自然キーだと特に問題が……あります orz」という状態なので、やむを得ないと思う。
「こういう要求があるから、よい」ではなくて「こういう要求があるから、やむを得ない」。


近しいので興味深かったのが「なぜ私はID派なのか( http://d.hatena.ne.jp/arn/20060903/p2 )」。

「二週間後に社員コード体系(数値→英数+桁数アップ)が変わるんで対応よろしく」とか。

これどう考えても「コード設計が致命的に破綻している」んだけど、現実問題として存在しているんだからしゃぁない。
もちろん「レベル(地位)を上げて物理(圧力とかパワハラとか)で殴る」って政治的解決法も存在しなくはないんだけど、「技術的に」解決させるのであれば「てめぇらのふったコードとかとても信用なんて出来ねぇからこっちで人工キーふって安全に運用するぜ!!」ってなるのもむべなるかな。
まぁ「ご愁傷様です」ってレベルですな。


あとは、ソシャゲなんかですと「IDはint! 文字列とかアリエナイ!」っていう価値観が一定数存在して、かつそれなりに合理的でもあったりするので。
そこで「既存のデータの候補キーがすべてstring」だったりしますと「じゃぁ別途、人工キーをば」って話にならなくもない。
まぁ「いやそもそものデータの候補キー(の1つ)をint型にしろやごるぁ」で片付くことも多いのですが(おいちゃんはこっち)。


「ORマッパーの都合としての人工キー」と、それに伴う「すべてのDBに`id`ってカラムを追加」については…そもおいちゃん、ORマッパー自体にあまり過度なメリットを感じていないので微妙ではあるのですが、基本的にはあんまりお好まないの感じ。
なので「ORマッパーの制限があるから」で「サロゲートキーに」って論法は、あんまりお好まないかなぁ。
フレームワークの都合で以下略」って状態なら止む無く受け入れない事もないけど、あんまり「是」とは言えないなぁ、という感じ。


次に「複合キーの混雑をさけるための人工キー」については。
弱めに反対だけど、さほど強固に反対でもないかなぁ、程度。
基本的には「ちゃんとSQL書けばいいじゃない」ってなるんだけど。それはおいちゃんの複合キーがせいぜい2カラム程度であることが多かったり、っていう側の事情もあるし。
(やっぱり好まない論点だけど)「ORマッパー的に面倒」ってのもあるし。
その辺を前提に「複合キーが関連するところは、ちゃんとユニーク制約なりぶち込んだ上で、別途サロゲートキーを用意、普段はそっちをよく使う」については、おいちゃんが仕切ってるところだとあんまりよい顔はしないんだろうけど、そこまで「駄目! ゼッタイ!」ってほど強固に反対するものでもないかなぁ、と。


なので、おいちゃんは「自然キー、複合キーありあり」が前提な一派一門に所属しております。


結論として。
もちろん「適材適所」ってのは大前提なんだけど、さりとて「高度の柔軟性を維持しつつ臨機応変に」なんていう虹色な発言は「何も考えてないのと同義だよねぇ」「行き当たりばったりとなにが違うのん?」ってお話になるので。


そんなあたりの理由から、なんとなく「現在のスタンスとか基本指針とか」を書いておきたかったので、メモ。