SQLアンチパターンを読んで、Railsエンジニアが特に印象に残った3つのこと

そろそろ暑くなってきましたね ☀️
マネージャー兼エンジニアのkyonsukeです。

最近SQLを改めて勉強をしていまして、その一環で読んだ有名書籍「SQLアンチパターン」の中からRailsアプリケーションエンジニアの僕が特に印象に残った項目を厳選してご紹介します!

1. とりあえずSELECT * でデータを拾うのは良くない

RailsとかのActiveRecordのORマッパーを使って、普通にレコードを拾ってくると、紐付けの関係でデフォルトではワイルドカードで全データを拾ってきてしまいますが、データの転送コストや拾い上げるコスト的には良くなく、やはり必要な分だけを拾うのがSQL的には正義とのこと。

特にレスポンスが気になるところでは限定した方が良さそうな印象です。
実際ORマッパーを使った際に拾い上げるデータを限定するのはスタンダードなのか気になっております。

2. SQLでのNULLは「何もない値」ではなく「わからない値」である

プログラム言語の文脈でのNULLはだいたい「何もない」という意味や「空」であるという意味で使われると思いますが、SQLの文脈では分からない値=NULLとなっているそうです。

なので、たとえばnameというカラムからNULLのである物を拾ってこようとして、

name = NULL

といった形に書きたくなりますが、もしnameにNULLが入っていても

NULL = NULL

となり、分からない値は分からない値と等しいか?という条件文となり、分からない値と分からない値が一致している保証はないので、falseとなります。

なので、ここでは

name IS NULL

といった特別な文が必要となります。
今までこの文が存在する意味を知らずに僕は使っていたので、なるほどなぁと感心しました。

3. 全文検索をサポートする仕組みはDBベンダー自体にもある

全文検索と言えばElasticSearchなど、検索エンジンを使うのが一般的だと思いますが、単純にLIKEパターンマッチを高速化したいだけなら、ベンダー拡張の全文検索技術もあるそうです。

Railsで主に使われているMySQLやPostgreSQLにも存在するので、こちらを使うというのも手かなと感じました。

(参考)MySQLの全文検索
https://dev.mysql.com/doc/refman/5.6/ja/fulltext-search.html
(参考)PostgreSQLの全文検索
https://www.postgresql.jp/document/9.6/html/textsearch.html

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です