DBの正規化は重要!タグ機能に関連するテーブルを作り替えた話

スポンサーリンク
Pocket
LINEで送る

DBの正規化を意識していなかったんですが、やっぱり重要だと気づきました。

 

タグ機能で問題が発生

開発しているサービスでタグ機能が欲しくなりました。

タグ機能とはユーザーの投稿に自由にタグをつけ、コンテンツのカテゴリわけができます。

カテゴリわけができることによって検索系で便利になります。

 

タグ機能を実装することになったわけですが、以下のリンク先に記載されたDB設計をすべて試してみました。

タグ機能を実現するための便利なデータベース設計を3つ紹介

 

タグテーブルと投稿とタグを紐づける中間テーブルを作るとレコード数が膨大になるなあと思ってMySQLicious法というテーブル設計を参考にしました。

この設計であれば、1レコードで済むのでレコード数が多くなることもないなと思っていましたが、別の問題が発生。

タグをカウントできない。。。

タグのカウント数を出したかったので、GROUP BYしてカウントしたかったんですが、そもそも一カラムに対して複数のタグが入れられているのでできない。

 

ということで、Scuttle法に変更!

タグテーブルのレコード数は増えるけどまあ仕方ない。

これでカウントできる!問題解決!

 

別の問題が発生。タグ名変えるとき、かなりめんどくさい。

このテーブル設計は投稿に対して、タグテーブルが紐付けられる設計です。

タグテーブルには(投稿ID, タグ名)というカラムがあり、

「ruby on rails」というタグを「Ruby on Rails」というタグに変えたかった場合に、対応するレコードをすべてにupdateをかけなければならなくなります。

これは、めんどう。

 

 

ということでToxi法に変更!

これは投稿テーブルと中間テーブルとタグテーブルがあり、第三正規形となっています。

これでカウントはできるし、タグ名の変更はタグテーブルの一レコードupdateするだけです。

スポンサーリンク

レコード数は増えますが、結局一番正規化されていた方が使い勝手がいいということがわかりました。

 

 

DBの正規化ってやっぱり大事

今回の件でDBの正規化の重要性を改めて知ることができました。

 

MySQLicious法は正規化されていない。

レコードが増えないというメリットがありますが、複数の値をカラムに入れるのはSQLのアンチパターンです。

 

Scuttle法は第一正規化

投稿とタグを分割できてるが、重複するカラムが出てくるので複数更新する必要がある。

 

Toxi法は第二正規化

投稿とタグと投稿とタグを関連させるテーブルとこれで更新が一回で済みます。

 

まとめ

DBは徹底的に正規化した方がいい。正規化するとテーブル結合が増えてパフォーマンスが落ちると聞きますが間違いみたい。

http://itpro.nikkeibp.co.jp/article/NEWS/20051114/224500/?rt=nocnt

 

ITは技術の進歩が早く、覚えた技術も時間が立てばすぐに「古い技術」になってしまいがちです。

一方、DB設計などの知識は資産となるので覚えておくといいです。

それにしても、DB設計おもしろい