第14・15回 SQL Server 2019勉強会より - はてなブログに引っ越し記念
はてなのブログに引っ越しました。
思い出したようにブログを再開したいと思います。
目次
Twitterは議論に向かない。
「第14・15回 SQL Server 2019勉強会」について、
イロイロとTwitterでご意見を頂戴しましたが、140字しか書けないTwitterは議論に向いていません。
ですから、勉強会では語り切れなかったことも含め、私の主張を改めてまとめたいと思います。
私の主張
SQLの方が息が長いからロジックをSQLへ寄せた方が良い
RDBMS（SQL）が本格的に使われ出したのは1990年代の中頃でしょう。
ちょうど、私がこの業界に入った頃です。
時代の流れとして、
・COBOLからの転換点
・Windows 95の発売（PCが一般化）
・Webの利用が一般化
・Y2Kの対応
という混乱要素がいくつも重なった時期でした。
その頃の言語の流行りは、VB4～6、Delphi、C++、Java（アプレット）と、今とはかなり変わっていてほとんど残っていません。しかし、言語が変わっても、「RDBMSを使う」というのは今もほとんど変わっていませんし、「RDBMS」が開発効率やパフォーマンスなどのボトルネックになるということも変わっていません。
30年以上、RDBMSについては、ずっと課題であり続けています。
しかし、現実的に一番息の長い言語がSQLです。また、テーブル構造とアプリケーションのどちらが寿命が長いかというと、テーブル構造です。
つまり、SQLにロジックを寄せた方がシステムとして長持ちします。
SQLが分かりにくいという常識とは？
私は CoderDojo のようなところで、子供たちにアドバイスをするメンターもやっています。そこではフローチャートがそのままプログラムになるという Scratch を使っています。
Scratchは、将来ほとんどの言語に応用できる基礎的な考え方が学べます。
つまり、フローチャートはほとんどの言語の基礎の基礎に当たるわけですが、SQLは他の言語と違いフローチャートでは表現できません。
別のイメージが必要になるのですが、ほとんどの入門書でイメージではなく文法の解説になっています。これが最大の問題です。
文法の解説をされると、他の言語の経験がある人は、自然に、
フローチャート → 言語
という慣れ親しんだ考え方になってしまって、それが通用しないSQLのとき混乱するわけです。
新人の中には、フローチャートのイメージができてないまま、文法を覚えてプログラムを書こうとする人が出ます。そんなプログラムは読めません。
同様に、SQLではかなりのベテランの人も、（WordPressの例にある通り）ほとんどイメージできてないまま書いています。そんな人たちが長いSQLを書くと、私が見ても意味が分からないものになって、メンテもできません。
書いた本人が、イメージを持たずに書いているのですから、他人が（書いた本人ですら）理解できるはずがないのです。
ですから、今のままでロジックをSQLに寄せたら大混乱になります。
当然、私は、「今のままロジックをSQLに寄せるべきとは言っていません」
教育からやり直すべき
しかし、SQLの教育は簡単です。
私は相当高いレベルのSQLを書いていますが、その私と同じレベルのSQLコーダーを育てるコストは、ハンズオンで3日あれば十分です。あらゆる言語の中でこれほど教育コストが低い言語はありません。
その方法は、勉強会でお話した通り、ベン図やエクセルでSQLのイメージをつかむことです。ですから、プログラム未経験であっても、エクセルを使って業務をしている事務職の方は、エクセルで処理するイメージを既に持っているため、SQLをあっという間に理解できるようになります。
嫌いな人に関わらせない！
そして、嫌いな人に関わらせないように開発手法を見直すべきです。
開発効率を高めるため、SQLが苦手な人たちが考え出したORMなるものがあります。ORMは、「SQLが嫌いな人にもSQLを隠して関わらせよう」というものですが、俺俺フレームワークにあるORMも含めたら、いったい何種類のORMが存在するでしょう。
それだけの数を作っても解決に至っていない。
というのは、ORMは最適解ではないと断言してよいでしょう。
ORMはMVCの概念でインピーダンスミスマッチを解消するために作られました。
しかし、ORMはMVCが持つ「違う機能は疎結合にしよう」という最も重要な概念に矛盾しています。
この構造でおかしいのは、全く違う構造を持ったSQLを「オブジェクト指向言語で何とか扱おう」としていることです。SQLはAPサーバでORMによって生成されて、DBサーバで実行されます。
スタンドアローン向けに考え出されたMVCの概念をWeb向けに発展させていくとしたら、一番に疎結合にすべきSQLを、Modelに取り込んで実行時に生成するというという謎の構造になってしまいます。
上の図のようにSQLをDBサーバ側に保存（ストア）し疎結合にすれば、オブジェクト指向言語で開発する人と、SQLを扱う人を完全に分離することができます。
現状のMVCに基づく開発では、オブジェクト指向言語を扱う人はSQLの知識もいる。
しかし、全員に高いレベルを要求してもできないから、多くの技術者が（フローチャートにすらならず）違和感を持つSQLの技術レベルを下げるということが起きている訳です。
特定の技術のレベルを下げれば、そこがボトルネックになるのは当たり前です。
しかし、勉強会でお話した通り、SQLを疎結合にすることができれば、
- オブジェクト指向言語はできないがSQLはできる人
- SQLはできないがオブジェクト指向言語はできる人
いずれも、活躍の場が生まれます。
そして、プロジェクト全体としては、特定の技術レベルを下げていないため高い品質を担保できるわけです。
議論にあたり
技術的な議論と、営業的な議論をごちゃ混ぜに意見するのは止めてください。
営業的な議論は、個々のプロジェクトによって違うことですから、公に議論しても意味がないことです。個々のプロジェクト内でやってください。
技術的な議論
技術者同士の議論について、「誰々が言ってる」、「みんなが言ってる」、「流行っているか」などを持ち出されても、それは何の論拠にはなりません。
「みんなが言ってる」が正しいのであれば、大地はいまだに平のままでしょう。
正しいか、正しくないか、自分の考えた理屈に従って、万人が何と言おうと、「それでも地球が回っている」と主張するのが技術者だろうと私は考えています。
営業的な議論
営業的には、「みんなが言ってる」、「流行っているか」などが意味を持つことがあります。（エクセル方眼紙のように）技術的に間違っていることでも選択することはあり得るのです。
10年ほど前に、「すべての変数をStaticで宣言したらしっくりくる」と言って大炎上した事件がありました。
すべての変数をStaticで宣言しても動くアプリケーションは作れ、ユーザに対する影響は軽微です。逆に、ORMを使うなど、SQLの技術を低くするということになり、ユーザに対する影響はもっと大きいです。
それなのに、なぜStaticオジサンは、大炎上させるのでしょう？
大炎上させるほどの技術者としての正義感が働く、その基準が私には理解できません。
「すべての変数をStaticで宣言」はひどい、と思うのであれば、「ORMを使うこと」はもっとひどいのです。ですから、営業的にORMを受け入れざるを得なかったとしても、「技術者としてあるまじきダブルスタンダードを受け入れたんだ」と理解して、次の機会に改善できないか考えていただければと思います。
