複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
NoSQLを超えるSQLデータベース「VoltDB」。Cassandraとベンチマーク対決！
「多くのOLTPデータベースは30年前の設計を基にしており、今日の“Webスケールな”データベースの負荷を想定していない。これら伝統的なデータベースは、処理時間の90％以上がログ、ロック、ラッチ、バッファ制御といったオーバーヘッドに費やされ、しかもそれらによって限られた性能やスケーラビリティしか実現できていない」 Ingresの開発者でありInformixのCTOなどデータベースベンダの要職を歴任したデータベース研究者の大御所、マイケル・ストーンブレイカー氏が開発したVoltDBはプレスリリースでこのように既存のリレーショナルデータベースの欠点を示した上で、インメモリデータベースをベースにこれらのオーバーヘッドを除去し、ACIDによるデータ一貫性を維持しつつ大きな性能向上とスケーラビリティを実現したと説明されています。 SourceForge.jpの記事「「NoSQL」を上回る性能を目指す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ネットマネーラボ
