複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
flint blog: 履歴を取ってみよう
けれども、この「更新日時」が実用にどれほど役に立つものかを考えてみると、その効果のほどは甚だ疑問です。 何故なら、このフィールドはあくまで「最終の」更新日時を表すものに過ぎず、次の更新が生じたときに、その値は上書きされてしまうもの。 その最終の更新についてさえ、「いつ」行われたかは分かるものの、「どのような」変更がなされたかについては、何の情報も提供されません。 そうしたことを考えると、この「更新日時」のフィールドは殆ど意味を持たないものだと言えます。 話は変わりますが、Mac OS においてはファイルへのアクセス日時が最終のものだけでなくすべてが記録される模様。 これは便利と言えば便利なのかもしれませんが、恐ろしい気もしますね。 閑話休題。 こうした事情から、より重要なデータを扱うシステムでは任意の時点におけるレコードの状態を参照できるようにするため「履歴」の情報を含めてデータベースに格
flint blog: でかいテーブルの恐怖
あけましておめでとうございます。 1月も既に半ばではありますが。 昨年10月の下旬から始まった仕事のスケジュールがこれまでと較べてかなりタイトなもので、ブログの更新もすっかり滞っておりました。 今回の仕事を含め、大学時代から、何故か他人が作ったシステムの分析・改修を手掛けることが多いのですが、それらの中には動作しているのが不思議なほどに設計・実装がグダグダなものが少なくありません。 特に、データベースを利用するような比較的規模の大きなシステムにおいては、そうした出来の悪さは「手の施しようのない」悲惨な稼動状態 (加えて、にも関わらずなんとかしなければならない凄惨な作戦状況) を生み出すことに。 このエントリでは、その要因の一つである巨大な (カラム数の多い) テーブルについて述べていくことにします。 テーブル定義が肥大化する要因を個別に検討する前に、私のおおまかな判断基準を示すと、 カラム
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
