テーブル設計やSQLを学びながら、速いデータベースの作り方について考えてみる

「Software Design 2018年5月号」を読みました。

ソフトウェアデザイン 2018年5月号

出版社/メーカー: 技術評論社
発売日: 2018/04/18
メディア: 雑誌
この商品を含むブログ (2件) を見る

「速いデータベースの作り方」という、データベース特集の会だったのですが、私なりの考えをまとめてみました。この時期は、新人エンジニアの方も多いと思いますので、少しでも参考になる何かがあれば良いかなと思いまして。

それでは、スタートです。

正規化

実務では、第１〜第3正規形がよく利用されます。理想は第3正規形なんですが、正規化をすればするほどテーブル数は増えるので、SQLが長くなったり、テーブル結合が煩雑になるといったデメリットもあります。

第4回データベースの正規化｜OSS-DB入門｜OSS-DB道場｜受験対策｜DBスペシャリストを認定する資格 OSS-DB技術者認定試験

私がオススメするのは、プログラムの定数やコンフィグファイルで賄えるマスタ系のデータは、極力テーブル化しないことです。

例えば、都道府県のデータは、テーブル化するまでもありません。「1 => '北海道', 2 => '青森県'・・・47 => '沖縄県'」と、定数としてプログラム上に記述しておけば良いのです。

このように、変更の確率が低いマスタ系のデータは、極力プログラム上の定数に書くことをオススメします。第3正規形で分離するようなテーブルでは、きっと対象となるようなテーブルも出てくると思います。

SQLとプログラムの使い分け

SQLの使い方を知った新人エンジニアの方の中には、SQLやテーブルを職人芸のように扱って、SQLで何でもやろうと考えている方もいらっしゃるかもしれません。

しかし、個人的にはあまりオススメしません。何故なら、DBサーバよりもプログラムが動くWEBサーバの方がスケール(並列化)しやすいからです。

それに、プログラムは後から処理を変えやすいので、変更に強いという特徴があります。速いデータベースの話をしているのに、プログラムで頑張れというのも変な話ですが、要はプログラムとDBのどちらで頑張るのかという、その見極めが重要なのです。

インデックス

インデックスが使われると、検索が早くなるのは有名かと思うのですが、意外とインデックスを貼ることに対するコストは無視されがちです。

当然ですが、インデックスを使うためには、インデックスの生成コストが代償として必要になります。つまり、検索が早くなるからといって、むやみやたらとインデックスを貼ってはならないのです。

・・・なので、インデックスは検索条件として利用頻度の高いカラムなどに絞り、利用シーンに合わせて設定する必要があります。

なお、気をつけてインデックスを貼るべき第二の理由は、インデックスの生成コストはINSERTやUPDATE文に対して発生するからです。データ参照のSELECT文は、DBのスレーブサーバーなどを立てて、負荷を分散することが比較的やりやすいのですが、INSERTやUPDATE文となりますと、そう簡単な話ではありません。

サーバの種類とDBサーバ超基礎入門 : LINE Corporation ディレクターブログ