SQLアンチパターン@Rails③クエリのアンチパターン

パターン13:恐怖のunknown(フィア・オブ・ジ・アンノウン)

NULLをある種の値のように扱ったり、あるいはnullに当たるような一般値を独自に定義するのは良くない、という話。Railsにおいては直接DBにふれることはないし、nilを返すようなカラムに何かしらの操作をしようとした場合はちゃんと例外出してくれるので心配ないと思う。

パターン14:曖昧なグループ(アンビギュアスグループ)

グループ内の最大（小、平均）値の値だけでなく、そのレコードの他カラムも取得するようなクエリを実行したい。
Railsではgroupでグルーピングのみを行え、そこからorderするといいと思う。

.rb

BugReport.group(:product_id).order(:created_at).first

パターン15:ランダムセレクション

takeを使えばいいと思う(実装を読んでるわけではないので、もしかすると良くないのかもしれないけど、今のところ非推奨という話は聞いたことない)

パターン16:貧者のサーチエンジン

全文検索を行いたい。なるほど確かになかなか難しいかもしれない。Railsの元々の機能としては提供されていない（と思う）ので、単純に紹介されているようなパターンマッチ述語を含むクエリを投げるしかないように見える。
ググったらいろいろ出てきた。やっぱりそれなりにありふれた問題なので、すでにソリューションはあるんだと思う。

• Railsで全文検索まとめ

• Mroonga

• Solr

• Elastic Search

今結構hotな話題なので勉強してもいいかもしれない。

本に名言があって、「問題を解決するために必ずしもSQLを使う必要はありません」

パターン17:スパゲッティクエリ

超絶技巧みたいなクエリを書くのはやめろ、という話。特にRailsにおいてはなかなかそんなことにはならないと思うので、心がけたい。たとえばwhereで死ぬほど長い条件を書くよりかはscopeを分割してチェーンする方が可読性も良いし、各scopeは違う場所で再利用できる。DRYの精神にも合致してて良い。

.rb

Model.where(condition1 and condition2 and condition3 and ...)

より

.rb

Model.condition1.codition2...

パターン18:暗黙の列(インプリシットカラム)

select *に見られるようなワイルドカードをなるべく使用するな、という話。主にパフォーマンスの問題と(そんなに大きな問題ではないと思うけど)コードとの整合性の問題。

pluckを使えばいいと思う。パフォーマンスはかなりいいよう。