おもいっくそ思考実験なので鵜呑み厳禁＆考えながら書いてるので多分文体めちゃくちゃｗ
まず。以前に、オラクルマスターとお仕事をしたりしてその流儀をしばらく使ってみたんだけど*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。>
