SQLのイメージと他の言語のイメージ３

　SQLで処理するイメージと、他の言語で処理するイメージを書いてきましたが、必ずしもSQLで処理することがベストと言えないこともあります。例えば、ガンダムのジオラマが最終目標だったとして、パフォーマンスや要望と、あるいは、プログラマの能力などを考慮した結果、顔の部分はSQLで削り出すよりも、他の言語でパーツにして組み上げた方が効率が良いと判断したとしましょう。

　最終のプログラムは以下の様になります。

SQLと他の言語を最適化したイメージ

　元のイメージと比べて、戻しやすいのはどちらか？
　他の言語でパーツの削りだしの形で考えていたら、設計図（仕様書）も膨大になりますが、一部をSQLにするときにそれまで考えていた物は跡形もなく無駄になります。材料まで戻らないと、SQLにはならないのです。

　複雑なSQLをデチューンしたことがありますが、考え方の順番として、SQLからアルゴリズムに戻していくのは簡単ですが、アルゴリズムからSQLに戻していくのは大変です。捨て去る部分が多すぎる。

　SQL以外の言語を得意とする人達は、詳細が分からないうちに部品単位に分解しようとしますが、それが後戻りの工数を大幅に増大させる理由になります。

　システムの詳細が分からない間は、すべてSQLで処理できるという前提で作っておく。つまり、UI以外はSQLで処理するつもりで作っておいて、詳細が分かってきた段階で、一部分を他の言語に移行するなり、ストアドプロシージャにするなりした方が最終的な工数が下がります。

SQLで処理する場合のイメージ

他の言語で処理する場合のイメージ