SQLアンチパターンを読み始めたので、1つ１つ書いてのメモです
目的
- スケーラビリティを高める
- クエリの実行速度を劣化させずに、データが増加し続けるテーブルに対応できるよう、 データベースの構造を設計すること
アンチパターン
- テーブルや列をコピーする
CREATE TABLE Customers (
customer_id NUMBER(9) PRIMARY KEY,
contact_info VARCHAR(255),
business_type VARCHAR(20),
revenue NUMBER(9,2)
);
カラム名に「2002」といった西暦があるカラムを増やしていくと、nullのカラムがどんどん増える
ALTER TABLE Customers ADD (revenue2002 NUMBER(9,2));
ALTER TABLE Customers ADD (revenue2003 NUMBER(9,2));
ALTER TABLE Customers ADD (revenue2004 NUMBER(9,2));
そこで、西暦ごとにテーブルを分割しようとする
CREATE TABLE Bugs_2008 ( . . . );
CREATE TABLE Bugs_2009 ( . . . );
CREATE TABLE Bugs_2010 ( . . . );
2011年のテーブルを作り忘れて不具合発生
- データの整合性の課題
- 2009 のテーブルに、2010が入っていた、ということが起こる
- データの同期
- 2009年1月3日のデータを、2008年12月28日にupdateすると整合性が保たれない
- 一意性の保証
- プライマリーキーの値をつくるためのテーブルが必要になる
- テーブルをまただいたSQL
- UNION で
- 新しい年になれば、SQLの更新が必要になる
- カラムの追加
- 全テーブルにする必要がある。そうしないと、UNION の対応が必要になる
- 参照整合性の管理
- 外部キーは単一のテーブル指定が必要だけれど、複数テーブルがあるのでできない
用いてもいいパターン
過去データを最新のデータから分離するようなアーカイブが目的のときです。
解決策
パーティショニングと正規化を行う
- 水平パーティショニング
- 垂直パーティショニング
- 従属テーブルの導入
まとめ
データにメタデータを増殖させないように気をつけましょう。
感想
- ソーシャルゲームの開発のときには、パーティショニングを使っていたので、解決策として正しかったのか、と安心
- でも、自前でやったらいけない
- メタデータって？
- データーのためのデータ
- 書籍であれば、筆者、出版社
- 写真であれば、Exif（f値、カメラ、色などなど）
