Help us understand the problem. What is going on with this article?

SQLアンチパターン:メタデータトリブル (メタデータ大増殖)

More than 3 years have passed since last update.

SQLアンチパターンを読み始めたので、1つ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値、カメラ、色などなど)

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away