SQLは最も高級言語

　SQLは現在、普及している言語の中で最も高級な言語です。

　高級か低級かというのは、どれだけCPU（の命令）と近いかです。CPUに近ければ近いほど低級でCPUから遠い、つまり、人間に近いほど高級言語ということになり、一般的に低級ほど扱うのは難しくなります。

　例えば、JavaではJava VMがCPUの違いだけでなく、OSの違いまでを吸収してくれます。しかし、より低級なC言語と全く同じ処理を書いたのと比べれば、Javaでコンパイルされたコードは冗長になるため実行速度が遅くなりますが、高級な言語ほどシンプルなソースで書けるから生産性は高くなります。

生産性とパフォーマンスについて

　理論値としては、同じ処理を低級言語と高級言語で書けば、生産性は高級言語ほど高くなります。

　では、アセンブリ言語ができる人が同じ処理をJavaで書いたとして生産性が上がるかというと、Javaもできるなら生産性は上がりますが、できなければアセンブリ言語の方が生産性が高いでしょう。生産性については「個人のスキル」という如何様にも設定可能なファクタの影響度が大きいため、「できる」「できない」の意見を出してくる人が入っては議論にはなり得ません。答えは「ｘｘｘのスキルが低いから」になるのですが認めないからね。

　SQLの議論において馬鹿げているのは、C言語（C++）とJavaの両方を使っているプロジェクトの例を考えれば分かります。

　ほとんどはJavaで作っているのですが、どうしてもパフォーマンスが必要な部分をC++で書き換えることはよくあるでしょう。このとき、JavaとC++のそれぞれのスキルが同程度であれば、ほぼ、理論通りに低級なほど生産性が悪くなりパフォーマンスが良くなります。

　SQLとJavaの両方を使っているプロジェクトで、SQLでできることをJavaで行えば理論的には生産性が悪くなりパフォーマンスも悪くなります。

　なぜかというと、相変わらずコアの部分でSQLを使っているから。JavaとC++でいえばC++で置き換えながら、コアの部分でC++からJavaのモジュールを呼び出すような馬鹿げた構造になるので、正確にはJavaとC++と同じ関係になっていない。JavaとC++と同様の対比をするならばRDBMSをNoSQLに置き換えないと行けない。そうすれば、JOINすら使えなくなるけれど高級言語と低級言語の理論的な関係となり、生産性とパフォーマンスがトレードオフの関係になります。

　結局、どこまでSQLでやるかの選択は、理論上は、SQLでできることはすべてSQLで処理すべき。逆に、SQLでできることを他の言語で行って生産性が上がると感じる人は、SQLのスキルが足りないだけの話で議論の余地はないのです。あるいは、できない人に合わせる必要があるという「できない人」がどれぐらいできないのか、どれぐらいの割合でいるのか、人それぞれ違うファクターが入ってしまう個別の議論（水掛け論）を仕掛けているだけなのです。

　もちろん、実際のプロジェクトとしては教育コストとのトレードオフで「SQLを選択しない」という政治決着はあり得ますけれど、教育コストは1度しか掛かりませんから、いつまでも「できない」という自称技術者を認めるべきではない。認めるなら、完全に疎結合にして担当を分けるべきなのです。

　余談ですが、SQLは非常に遅いです。SQLが流行るまで非常に時間が掛かったのは、SQLの思想にマシンスペックが追いつくのに時間が掛かったからで、NoSQLでできることなら、絶対にNoSQLの方が速いです。しかし、何度も繰り返しているとおりRDBMSを使うならSQLを使いきらないと遅くなります。

SQLを使わない方が生産性が上がる例外

　SQLを使わない方が生産性が上がる例外としては、単純なシステムでRDBMSの依存度が極めて低い場合です。更に、再利用性の高いオブジェクト指向言語の特性がぴったり合うシステムで、パフォーマンスに問題がなければ生産性が上がることもあるかも知れない。

　そりゃ、RDBMSの依存度が低ければ、それだけファクターとして小さくなるから当たり前の話です。