バーニング・ラブ・SQL

SQLについて調べていたら、すごく詳しい記事を書いてる方がいたのですの。
生島勘富さん、という方ですの。

「艦これ」についてのまとめ #艦これ
http://d.hatena.ne.jp/Sikushima/20131230/1388375483

初級シスアドはユーザ向けの試験で、プロはできて当然！
http://el.jibun.atmarkit.co.jp/g1sys/2009/07/csql-bbbb.html

どうも、キワな方が多いことで個人的に有名な@ITのエンジニアライフで、コメント欄を炎上させて執筆陣から除名になった方だそうですの。
あそこのコメント欄、過疎か炎上の二択しかないきがしますの。

さておき、SQLと、それを中心とした開発についての愛と知識は本物だと思うのですの。

いくつか記事を読んだ限り、この方が一番よく主張しているのは、
「SQLは、APサーバ側の言語（Java、C#など）からDBアクセスのために呼び出される添え物、ではない」ということのようですの。

DBMSを使う以上は、なるべくSQLで処理をするのが（ほとんどの場合）良い、と。

なぜかというと、そもそもDBMSを使う以上は、そこにデータを集めていくことになるので、データを扱う処理はすべてDBを通すことになるわけですの。
そういう状態で、処理の主体をAPサーバに置こうとすると、DB・APサーバの間で処理がぐるぐる行ったり来たりする非効率な構造が生まれやすいということですの。たぶん。

また、SQLは、それさえちゃんと書ければ、設計から開発までぜんぶ出来ると言ってもいいくらいの言語なのに、その割に教育がすごく手薄で残念、もっとみんなSQLを勉強するべき、、ということもよく書かれていますの。

わらわもSQL苦手なのですけど、そうやって丁寧に「むしろSQLこそがメイン」と言われると、そうかも、と思ってしまいましたの。


ほかにも、C#とか使ってて、DBとやり取りする部分のコードが綺麗に書けなくて、、っていうのは、けっこうみんな悩みどころだと思うのですけど、この方いわく「ストアドでDB側に置いてしまえば、そういう汚い混合コードを書かなくても済む」といわれていて、これもなんだか納得ですの。

ストアドを多用すると、処理の在り処が散らばってわかりにくくなる…と思っていたのですけど、主体がAP側っていう先入観を捨てれば、かえって全てDB側にまとまって見やすいかもですの。

それに上でも少し書いたように、構造上、AP側はDBを無視して完結することは出来ないけれど、DB側はそれ自体で完結することが出来るはずですの。それなら、処理をどちらかにまとめたい場合、DB側にまとめるのは悪くない筋だと思うのですの。たぶん。