クラス設計とテーブル設計のちょっとしたDiff

すごい久々のエントリですｗデブ沙汰しています。

半谷さんからバトンタッチしました♪ マンガなので読みやすく、それでいて内容はグッと来るので是非見てください♪

このエントリ記事はDevLOVE Advent Calendar 2015の「Diff」11日目の記事です。

今回は今年実施したSQL アンチパターンの勉強のときに感じた違い(Diff)になります。

今までDBはメンテナンスが多くてキチンとSQLの勉強をしたことがなかったので、チームの有志であの t_wadaさんが監訳したSQL アンチパターン勉強することにしました。

その第3章を勉強してたときのことです。「IDリクワイアド」といって、全てのテーブルに（何も考えずに）id列をつけてしまうというアンチパターンでした。その中に列の名前付けの話が書いてあったのですが、例えばBooksテーブルの場合はid列よりbook_id列が推奨されるとのことでした。

一方、Bookクラスの場合、メンバ変数nameやidとはしますが、bookNameやbookIdとはしませんよね？昔オブジェクト指向を勉強したとき、Book.bookIdとなるとブックブックしちゃうので、だからBook.idとなるようにnameやidを付けるのですと書かれたのを見てなるほど！！と思った記憶があります。

そのことを思い出して、どうしてSQLの場合はid列ではなくてbook_id列が推奨されるのだろうと参加者と一緒に考えてみました。その結果、テーブルは他のテーブルとも結合されるため、様々なテーブル間で一意になるように、idではなくbook_idと付けた方がいいということが分かりました。 idだとBooksテーブルのidもReservationsテーブルのidも見分けがつかないですもんね。しかも2つのテーブルに同じ名前の列名がある場合はUSINGを使って簡潔に書けるとのことでした。

SELCT * FROM Books INNER JOIN Reservations USING book_id

SQL アンチパターンにはもしidとしてしまうと冗長なON構文を常に使う必要があると書かれています。

SELECT * From Books As b
INNER JOIN Reservations As r
ON b.id = r.book_id

ON構文は冗長である。ｶﾞ━━Σ(ﾟДﾟ|||)━━ﾝ普通だと思ってた･･･

普通にSQLを書いている人にとっては、あたりまえだね～と思われるかもしれませんが、メンテばかりしていると気づきにくいものです（言い訳ｗ）

ある日DBの新規設計を任されたら、id列としていたと思いますので、やっぱり素振りって大切だと再認識しました。個人的にはクラス設計とテーブル設計のDiffを感じたところだったので今回のエントリとして書かせてもらいました。