MySQLの関数の使い方で解り易くまとめている下記のエントリーについて。SQL関数は覚えていたら便利な事この上ないのですが、１点だけ賛同できないことがあります。それは、プログラム中にMySQL中の関数を使う事そのものです。
プログラムのコード量を減らす MySQL 関数 | バシャログ。
時と場合によりますが、次の３つの理由で止めた方が良いのではないかと考えます。
１．DBの負荷対策が一番コストが掛かる
２．DBがボトルネックになり易い
３．アプリケーションの保守性が下がる
１．DBの負荷対策が一番コストが掛かる
一般的に言って、DBサーバはスケールアウトし難い部分です。単純に参照系だけであれば、レプリケーション等で割合簡単にスケールアウト出来ますが、更新系までのスケールアウトを考えると中々大変です。Oracle RACのようにお金で解決する場合と、アプリレベルで負荷分散と工数を掛けて対策する場合の２パターンがあると思います。もしくは、MySQL Clusterのようなソリューションもありますが、癖が強いので安価な高可用性ソリューションとは言い難いです。よってebサーバの増設よりコストが掛かる事が多いので、なるべくDBに負荷を掛けない構成が望ましいです。
２．DBがボトルネックになり易い
１の理由によりDBサーバの負荷対策は難しいです。よって良くある構成が、複数台のWebサーバと１台のDBサーバもしくは1台のマスターDBと複数台のスレイブDBという構成だと思います。この構成だと必然的にDBサーバがボトルネックになり易くなります。SQL関数や複雑なSQLを実行すると当然DBの負荷は掛かります。出来るだけDBサーバには負荷を掛けないように単純な処理をさせるのが良いと思います。
３．アプリケーションの保守性が下がる
MVCモデルで言えば、DB操作についてはモデルの役割になります。そして日付や文字列をどう表示するかはビューの役割になります。モデルがビューで表示することを考えて整形していれば、画面の表示パターン分だけモデルが増殖します。そうなると、計算ロジックが変更になった場合複数のモデルを変更しないといけない事態になる可能性があります。そうなると修正工数はもとより、ロジック検証のテスト工数も膨れ上がります。
また、O/Rマッパーを使う場合、SQL固有の関数等はサポートしていないことが多いです。そうなると、ネイティブSQLを記述することになり、もはやO/Rマッパーを使う意味がなくなります。
上記のような理由でSQL関数をプログラミング中で使う事には賛同しかねます。もっとも便利なことは事実なので、積極的に覚えて調査時などでワンタイムSQLの発行に活用すれば良いかと思います。
