Home > あいそるニュース > SQLを外出しファイルにした場合の注意点
SQLを外出しファイルにした場合の注意点
2008-11-26 04:54
SQLを外出しの設定ファイルにする理由
前回「SQLを外出しの設定ファイルにする理由」という記事を書きました。 この記事が多くの人に読まれているようですので、前回の記事で伝えきれなかった注意点を補足として述べたいと思います。
以下の内容は前回の記事の内容を理解していただいた方を前提として記述しております。 まだ御覧になってない方は、先にこちらをご確認いただければと思います。
SQLの共通を図ってはならない
SQL文字列をハードコーディングせずに設定ファイルに外出しする理由は先の記事で述べたとおりSQLコマンドインジェクション対策です。
SQLの共通化が目的ではありません。逆にSQLの共通化はやってはならないといつも社内の開発者には言っています。
具体的には下図の左のようなSQLの共通化はＮＧです。 SQLはソースコードの一部と考えるべきです。仕様が変更された場合はSQLも変更になる可能性が高いものです。 よって下図の右のように分離したSQLはソースコードと一対一にすべきです。
下図の左のような共通化をしてしまうと、仕様変更でSQLを変更することになった場合、そのSQLの依存に足を引っ張られて他のソースコードにまで影響を及ぼしてしまい、全体的にメンテナンスがし難いアプリケーションとなってしまいます。
弊社のフレームワークのSQLの定義ファイルにはそのSQLを特定するidを記述するのですが、idの命名規約はクラス名+連番ということにしています。 つまり複数のクラスからSQLを共通的に使用出来ない命名規約にしています。
共通化を図るのであればSQLではなくソースコードの共通化を検討する
仮にあまりにも同じSQLをいくつも定義していることに気づいた場合は、 それはSQLを共通化するのではなくソースコードそのものを共通化して切り出すことを検討すべきです。 具体的には下図のような考え方になります。
以上となりますが、そもそもにSQL文字列をハードコーディングせずに設定ファイルに外出しするのは、 大量にSQLを扱う大規模アプリケーション開発に有効なものです。
先の記事でも述べたとおり、 弊社のフレームワークでは開発者に対してSQLとソースコードを分離することを強いる仕組みになっており、 弊社のフレームワークを使用しているWebアプリケーションは必ずSQLコマンドインジェクション対策がなされていると保障が出来ます。
逆に小規模なWebアプリケーションの場合は、注意してSQLコマンドインジェクション対策を徹底すればよいだけですので わざわざSQLとソースコードを分離するメリットは少ないと思います。
Posted by T.S
