gallu’s blog

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

DBの、特に削除と候補キー周りにまつわる思考実験

おもいっくそ思考実験なので鵜呑み厳禁&考えながら書いてるので多分文体めちゃくちゃw


まず。以前に、オラクルマスターとお仕事をしたりしてその流儀をしばらく使ってみたんだけど*1………うん正直トラブルを引き起こしやすかった。
いや別に善し悪しをどうこうというわけではないので念のため。


一つ目。いわゆる「削除フラグ」を必ず盛り込んでいたんだけど…うんこれが使いにくい orz
ほかでも思ったンだけど。多分、彼の流儀は「全てを人工キーで処理する」んだろうなぁという感じ。
自然keyに削除フラグ付け始めるとPKの意味合いが壊れる(苦笑
直近だと。携帯サイトで、[iモードID | サブスクライバID]を識別用に使ってたんだけど。これをkeyにすると、削除フラグとの相性が悪い。
でまぁ 別物として処理してたんだけど、つい削除フラグを考慮し忘れたバグが結構あった。


いやまぁ「何らかの共通なルーチンでフォロー」すればよいんだろうけど…MagicWeaponを見据えて「アプリケーションをまたいで」って考えると、正直少々面倒。
っつか「自然keyをPKに出来ない」のがなんとも歯がゆい。


で、考えた。


なんで削除フラグが必要なのか。多分あれは「間違えたとき用のundoのために」なので。…ンないらんデータを必要なテーブルで保持する必要はないんじゃないかと。
例えば。hogeテーブルに対して、hoge_deleteテーブルを用意する。
hoge_deleteテーブルは常に「hogeと同じアトリビュート+"delete_date"を持ち、keyは存在しない」。
これで「必要なら頑張って探してundoしてよ」と言える。
data_clump*2のdelメソッド作り替えりゃいいかなぁ。


2008/07/11:削除&追記 start
><もいっちょ。
RDB的には「keyってアトリビュートの集合」ってイメージがあるんだけど件のオラクルマスターは「複数カラムにわたるキーはおかしい」と言っていたってのはおいといて。
「複数アトリビュートにまたがる候補キー」をcreate tableとかで指定する方法が、MySQLとかPostgreSQLとかだと見つからないっぽい(探し方が下手なだけかもしれないんだけど)。
なので。これをうまく設定化できて、data_clumpでinsertやupdateの時にはじけないものかなぁと。
そうすると、一部の「うざくて本質的じゃないチェックロジック」から解放されるような気がする。
んと…PKも含めて…例えば…PKって設定するところにc1とかc2とかって名前で区別するとか*3。>

*1:その流儀が「Oracleの流儀」なのか「彼の流儀」なのか「彼に教え込んだ現場の流儀」なのかは不明

*2:MagicWeapon内のクラス。結構特徴的だと作者本人は思ってる。

*3:ごめんこれはclumpの設定っつか継承クラス見た事ないとわからんと思うですが…こんどちゃんと書きます orz