SQLアンチパターン読書会参加記録7章と8章
２週間に一回ギークラボ長野で開催されているSQLアンチパターン読書会のメモです。
今までも時々参加していましたが、個人的にはアウトプットは必ずしていきたいので今回参加分からメモを残していきたいと思います。
マルチカラムアトリビュート(複数列属性)
連絡先テーブルに電話番号を持たせる場合、自宅、携帯電話、職場、FAX等の４つ分電話番号のエリアを用意すれば良さそうですが、携帯の2台目とか４つだけでは収まりきれない場合はどうすればよいのか？というのがテーマです。
本書では電話番号の話は最初だけで バグに対するタグ付けの情報をどう持たすかという例で進みます。
バグ情報にタグ付け（パフォーマンス、クラッシュ、印刷機能)をしたいということです。
〇アンチパターンな設計
これだとタグを4つ以上付けたいときどうするのか、また、パフォーマンスに影響するバグを探したいときに
where 'パフォーマンス' = タグ１ or 'パフォーマンス' = タグ2 or 'パフォーマンス' = タグ3;
などと検索しなければならずめんどくさいSQLになってしまうなどの欠点があります。
結論としては別の従属TBLを作成して解決になります。
まぁそうだよねって話ですが、少なくとも最初の例で出てきた電話番号の例ですと連絡先TBL.電話番号1〜3のような設計は普通にしてしまいそうだし、電話番号を別TBLに出すような設計を出した際に、上司を説得出来るかどうかはよく分かりません。
目的としてはデータの量が増え続けるTBLに対する速度低下をどうやって防ぐかというものになります。
バグテーブルにいつそれが発生したのかという日付を持ちたい場合で話が進みます。
テーブルの容量はどんどん数が増えるのでそれを年単位で分けて持ちたいという話です。
色々な例がでてきますが、解決策としてはパーティショニングと正規化を行おうというもの
〇水平パーティショニング
バグTBLを報告日の年単位でいくつかのテーブルに分けるように設定ができるようです。(これはしらなかったので普通にすごい！)
〇垂直パーティショニング
別の例として、Blob型やtext型を別の従属テーブルに切り離すことで処理を軽くすると言う話もありました。
(今回の例では直接関係なさそうですが)
〇解決
解決は7章と同じく従属テーブルの導入、、なんですが、バグ管理の話なのに突然違うTBLがでてきたのでよく分からないですね！！
バグの親にあるプロジェクトを年単位の子を持たせることで、その子であるバグも取りやすくなるよ？？ということでしょうか？？
注にはサマリーテーブルの改善であることに注意とありますが実は欲しかったのはバグのフィックス数だけで2016年に発生したバグの詳細はいらないということでしょうか？？
最後よく分からなかったのですが（というかよく分からないことに今気付いたのですが、）とりあえず正規化しようぜ！って話でいいのかな・・とも思ったり(^0^;)
うーん、どこかで本書で想定されているTBL全体が分かってないとちょっとついて行けないですね。。
追記
テーブル全体の構成は本書の最初の方に乗っているという指摘を頂きました。
@nakajidamedeath "どこかで本書で想定されているTBL全体が分かってないとちょっとついて行けない"
— とみたまさひろ (@tmtms) 2017年3月16日
「はじめに」の「サンプルデータベース」を見るんだ！
BugsTBLはProductsTBLと多対多の関係を持っているので、Productの子に新たに作ったProductHistoryBugsを作ってそこでバグの件数を持つようにすればいいんだよという話のようです。
結局欲しかったのは ある年のバグの総件数だけってことなんですね〜
詳細も含めたある年のバグ一覧が欲しいのかなぁとおもっていたのでちょっと認識相違があったみたいです。
理解してないのに読み飛ばしてしまうことがあるので、やっぱり読書会はためになります。
余談ですが
とみたまさひろ (@tmtms) さんがSQLアンチパターンに参加されますと面白い話や補足的な話がかなり聞けるので大変面白いです！
途中からでもデータベース設計を仕事でやりそうだ！って人は是非ご参加下さい！
