2007-09-20
主張の矛盾を許容することなんじゃないかと思い始めた。 以前から履歴管理をするリソースってどういうモデル設計にすれば良いのか悩んでいたのだけど、なんとなく解決策が見えてきた。 まず重要なのがID。IDは実装技術なのだけど、この履歴管理するリソースを扱う際には非常に重要。まず、例として商品マスタを考える。要件としては次のような感じ。 当時のイベントからは当時の商品名が参照できること 特定の日付時点での商品名が引けること 単なる間違いは直接修正したい 利用開始日より前にマスタを登録するが、期日が来るまで有効にならないこと 利用終了日が設定できる コードを変更しても串刺し検索が可能 まず、1番目はイベントにIDを付けておくだけで良いので、次のようなテーブルにすれば問題は解決する。 ID 商品コード 商品名 1 A001 おでん100% 次に「特定の日付時点での商品を引く必要がある」ので、少なくとも
ID or not ID - A.R.N [日記]
おぉ、ガチだ。 [RDBMS]複合主キー？ 18:57 ･･･まだそんなこと言ってる人いるのか。 id等の単一のサロゲートキーを導入して逃げることも可能ではあるが、そのために仕組みが複雑になることが避けられない。 いや、お互いものすごく優秀で有名な方だし大人なのでガチの勝負はしてくれないとは思うのだけれど、ぜひ世の多くのさまよえるSEのためにガチンコ勝負して決着つけてくれんかなぁ。てゆうか、今回の案件でもID派（＝私）と複合主キー派（＝モデラー）でもろに喧嘩してるし、前のプロジェクトでも他の人が同じようなことやってたし、さらに前の案件でも(w そろそろ、IDを使うべきかそうでないかくらいベストプラクティスを決めてほしいなぁと思う今日この頃*1。 たしかにDB直接見て何かするような運用だと、複合主キーの方がわかりやすかったりするのはたしか。でも複雑なシステムで他のテーブルへの関連が沢山あるよ
![ID or not ID - A.R.N [日記]](https://cdn-ak-scissors.b.st-hatena.com/image/square/0b9f5dd5b04b969b65543d66daeabf09d2f67327/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127064254481%2F17680117127064335398%2F1555805246)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
