Scribble at 2021-04-12 10:07:36 Last modified: 2021-04-13 22:23:38

データベースを理論として学ぶ際に必ずお目にかかるのが「正規化」という課題である。非正規にまとめられている表から始めて、第一正規形、第二正規形と進んでゆき、最初は一つのテーブルだったものが徐々に分割されてゆく。このような手順はデータベースが relational であるという想定の元で進められるため、テーブルどうしの関連付けという観点で逆に分割されていて、正規化してゆくと色々な利点がある。たとえば、重複する項目を独立したテーブルに追い出して一つの値にしてしまえば、そのテーブルを参照すれば値として取り出せるため、同じ値を共有するレコードで値を後から変更する場合に、独立させた参照先のテーブルで値を変更すればいいだけなので、該当する値を全て一度に漏れなく変更できる。

ただ、常にデータベースを正規化すればいいかと言えば、そうでもない。その典型は、レコードとしてログのようなものしか挿入しない場合だ。そもそも、NoSQL のようなデータベースの提唱はビッグデータに代表される膨大な量のレコードを扱う際に、その典型的な用途としてログの解析や検索エンジンのインデックス・データの格納が想定されていたことによる。このようなデータを扱う場合、寧ろ relational 型として格納したテーブルどうしを「関連付けて」から解析結果を出す方がパフォーマンスとしては落ちてしまう。値の重複は重複したままでよく、それらを幾つの重複なのかと数える処理は後でよいという発想だ。

また、逆にレコードが少ない場合も敢えて正規化しないことがある。なぜなら、通り一遍等に正規化するとデータの見晴らしが悪くなるからだ。或るレコードについて関連するデータが他のテーブルのこの値で・・・などと、〈人が〉関連づけを辿るのは大変だからである。そして、データベースに格納されているレコードの様子を確認するのに、わざわざ Splunk のような専用ツールを使うことは実際には少なくて、だいたい phpMyAdmin のテーブル表示を眺めていたりすることが多い。

正直言って、正規化することによるパフォーマンスがどのていど影響を受けるのか、単なるログとして、たとえば問い合わせフォームのデータとかプレゼント応募フォームから入力されたデータとかを扱っているだけなら気にもしない。正規化してもしなくても、そういうことは開発者の好きにすればいいというのが、大方のウェブ制作の現場で共有されている感覚だろう。大手企業のキャンペーンでプレゼントの応募フォームを運用する場合でも、応募件数なんて1ヶ月に10万件もあれば多い方である。そして、昨今のストレージや CPU パワーなど、コンピュータのリソースにかかるコストはたいへん安いので、正規化せずにいるデータベースで(恐らくは)無駄にかかる負荷やコストなんて、クラウド・サービスを使っている場合には、メモリを 1GB 増やしたり CPU のコアを増やして、それこそ金で(しかも月額ですら僅か数千円で)簡単に解決できる問題でしかないのである。

ただ、正規化という考え方そのものを札束で払い落とすような態度は決して勧められない。正規化というアイデアを維持していることによって、データベースの設計つまりはどういうデータをどう残すかという仕様を考案するのに適切な考え方を維持できるからだ。パフォーマンスは金で解決できても、まだまだ自動化ツールなんて理論化すら満足にできていないシステム設計というフェイズにあって、札束で適切な仕様を作り出すことはできない(その札束で適切な仕様を考案できるかもしれない人材を派遣会社から呼んでくることはできるかもしれないが、それは別の問題である)。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook