SQLアンチパターン 感想

SQLアンチパターン

SQLアンチパターン

今やってる仕事でSQL(正確にはPL/SQL)を扱っており,
その絡みで購入した次第.読む時間中々作れず2か月かかって読了.

SQLとはご存知のとおり,関係データベースを操作するときに使用する言語.
どんな人でも,大なり小なり触れたことはあるんじゃないかな.

そして,おそらくほとんどの人が,
「あれ?目的はシンプルなのに,何故こんなにクエリが複雑になるんだろう?」
と苦労した経験があると思う.
そういうときは,まず,
この本に書かれているような「アンチパターン」に陥っていることを
疑うべき.そして,早急に対処すべき.

1点補足すると,この本における「SQL」の多くは
DDL(データ定義言語)」のことだと思ってくれて良いと思う.
即ち,テーブル設計がグダグダだと,
それを扱う人が,上述のような地獄を見ることになるぞ,
というのが本書が訴えたいこと.

その実例として様々な種類のアンチパターンを紹介しているけれど,
ザックリ集約すると,以下の3パターンに分類できると思う.

・中途半端な正規化
・EAV(Entity-Attribute-Value)
・性能に無頓着な設計

正規化とは,乱暴に表現するならば,
「テーブルを可能な限り分割する」行為を指す.
オブジェクト指向設計における単一責任の原則と,発想は似ているかな.
これが出来ていないと,複数テーブルを組み合わせて情報を取得する際に
ものすごく苦労することになるし,仕様変更にも弱くなる.

EAVとは,書籍内の表現を借りるならば
「属性を行に格納すること」
となる.
これを導入すると,テーブル定義を変更することなく
様々な情報をRDBMSに格納できるようになるので,一見便利に思えるんだけど,
やはり様々な不具合の温床になるので,避けた方が良い.

RDBMSと性能は,切っても切り離せない問題.
簡単には解決できない上に,性能を追求しようとするあまりに
他のアンチパターンに陥ってしまうケースも間々あるので,銀の弾丸は存在しない.
この本でもそのあたりは心得ていて,
性能に関する主張は「絶対にNGなインデックスの張り方」など,
一般論に留まっている感じ.
逆に言うと,ここに書かれていることすら留意できていないと論外,ということ.

この類の本の感想で毎回言っている気がするけれど,
書いてある内容自体は
「いや,そりゃそうでしょ」
というものが多い.
それでも,こういう本が売れるのは,すなわち,
それすら守れていない残念な自称エンジニアが世の中には沢山存在し,
その人たちの残念な設計のせいで,他のメンバが苦しめられているからに他ならない.

SQLに関わる人は,こういうアンチパターンに陥らぬよう,
また他者が陥りそうなときは全力で止められるような,
そんなエンジニアを目指してほしいと思う.


現在進行形で前任のクソ設計に苦しめられているので,今回若干恨み節増量.