良書良書と聞いていたSQLアンチパターンですが、題名からSQLに特化した内容と思い込み、今まで読んでいませんでした。
先日、本書に記載されている「とりあえずID」のアンチパターンを踏んでいることを指摘いただき、購入に至った...という経緯です。
※電子版が欲しかったため、オライリーから購入しました。
本記事には、第1部をゆっくり、他部をざっくりと読み進めた際、思ったこと等を記載します。
新卒に入ったプロジェクトでは、第1部に記載されていたアンチパターンを全て網羅していた（唖然）
2013年発行ということもあり、本書を題材に公開された記事やスライドが豊富です。そちらのリンクを貼りながら、実際に業務で体験したアンチパターン事例を記載していきます。
ジェイウォーク（信号無視）
www.slideshare.net
製品の不具合理由（複数）を保持するため、IDをカンマ区切りで保存させていました。マスタからレコード削除することで、例外発生...みたいな苦い記憶が蘇りました。
ナイーブツリー（素朴な木）
www.slideshare.net
製造業における、BOM)の素材 - 製品表を表していました。やはり、階層が深くなるたび検索性が悪くなり、UNIONやサブクエリを駆使して抽出していた覚えがあります。
IDリクワイアド（とりあえずID）
このアンチパターンを踏み、本書を手に取りました。 😇
ノータイムでORMから生成されるIDを定義していたので、今後注意していきたいと思います...。
キーレスエントリ（外部キー嫌い）
www.slideshare.net
外部キー制約により、意図しない削除を防ぐため...といった理由から、外部キーを設定しなかった記憶があります。でも、これにより、データパッチを当てた際、考慮漏れにより出たゴミレコードが残るといったことがありました。
EAV（エンティティ・アトリビュート・バリュー）
製品の設計情報をマスタ管理していたのですが、よく項目が変わるため、EAVを用いていました。
当時はORMも使っていなかったため、対処としてはシングルテーブル継承になると思うのですが、柔軟性を考慮してEAVにしてしまったのかな...思いました。
ポリモーフィック関連
共通・個別の製品情報を管理するために用いてました。これもデータパッチ対象のテーブルに漏れがあると、ゴミレコードが発生してました。
マルチカラムアトリビュート（複数列属性）
コンボボックスで選択された値に応じて、画面項目を変動させるため、Field1〜50のようなカラムを設けていました。
メタデータトリブル（メタデータ大増殖）
www.slideshare.net
言わずもがな、年別にテーブルを分けてました。
ただ、要件的に最新1年のデータのみを参照できるようにすればいい（他データは、保守で抽出してもらえればいい）というような制約があったため、すぐ考えつきそうなこのアンチパターンが用いられたのかな...と思います。
自分が知っている手法は、すべてアンチパターンじゃないかと思える
アンチパターンだらけのアプリケーション開発をしてきましたが、それがアンチパターンとも気づきませんでした。（当時、冗長・保守性に乏しいからどうにかしたいと思いつつ、問題提起したところで変わらないな...と思い、放置してました。）
そのつけが今、自分にも降りかかってると思うと、自業自得です。
今年はどうあるべきか、どうしないべきかが語られている本を漁ろうかなと思います。
参考になりそうな記事・スライド
ググってた際、包括してSQLアンチパターンについて説明してる記事やスライドがありましたので、まとめときます。
- 2013 JavaFesta t_wadaさんの発表資料
- 「SQLアンチパターン」を避けるためのチェックリスト①（DB論理設計編） - log4ketancho
- 【感想】SQLアンチパターン - Rのつく財団入り口
-
O'Reilly Japan - SQLアンチパターン の目次タブ参照↩
