プチ炎上したのでまとめ
「炎上してでも議論がしたい」
と書いたおかげか、プチ炎上しました。
御意見いただいた皆様、どうもありがとうございました。
こんな長ったらしい文章を読んでいただいた皆様も、ありがとうございました。
10年近く言い続けていることですが、賛同いただけることも以前より増えてきたし、以前の反論はほとんど感情論でしたから、ずいぶん議論がしやすい環境になってきたなと実感します。
私なりのまとめです。
■適用範囲の条件は？
あくまでも「RDBMSを使うシステム」の話です。
「RDBMSを使わないシステムもある」という御意見も頂きましたが、それは最初に断っておくべきでした。
また、あまりSQLを使ってこなかった人は、自分の中でSQLの限界を決めているようです。
しかし、弊社の例では、中小企業とはいえ100機能（画面数・帳票数ではなく機能数です）程度の基幹システムでも、ユーザーインターフェイス・外部インターフェイス以外は、SQL（ストアドプロシージャ）で処理できています（ちなみにDBはPostgreSQLです）。
大手商社の為替機能を担当したときも同じです。
ですから、条件としては
- （MySQL以外の）RDBMSを使うシステム
- 100万円以上の規模
（100万円以下では、わずかに工数が下がり体感速度は変わらない）
つまり、いわゆるSIerが手掛けるほとんどのシステムが対象です。
大きいシステムの方が効果も大きくなります。
■技術（言語・手法）の限界値について
ある技術を選択したとき、できること・必要工数・パフォーマンスなど、各種の要素について限界値が存在します。その限界値は未知の可能性もあり、それまでの限界値と思われていたものを超えることができる人が出てくれば、塗り換わることになります。
私は私なりに、Javaやオブジェクト指向の言語にロジックを寄せてシステムを構築した場合の限界値を持っています。その限界値と、私が持っているSQLを中心にしてシステムを構築した場合の限界値を比べSQLで構築した方が効率的だと考えています（ここはシステム要件によって変動が大きいので抽象的な言い回しで申し訳ない）。
それは、私がJavaなどの技術が未熟だからかもしれません。
ですから、常に塗り換わる可能性を模索して、議論を求めています。
ところが「SQLで処理した方が良いよ」と話してもことごとく反対されのは、Javaなどの限界値が高いからではなさそうです。
今回のプチ炎上でも、今のところありません。
逆に、反対する方は、私の想定よりも遙かに低いラインにSQLの限界値をもっているようです。ラインを上げるために、「これぐらいは会話のスピードでできるでしょう？」とお話しているのですが、ラインはなかなか上げてはもらえない。
■技術は限界値で議論すべき
技術（言語・手法など）には、上には限界があり下を見ればゼロです。
つまりできない人は、どこまでもゼロですから（できないので）、どんな技術を選択しても、どんな言語を選択しても、どんな手法を選択しても、ゼロから、（理論上の）限界値までの差が生まれます。
例えば、あるシステムをすべてアセンブラで書いたとします。
この場合、アセンブラの達人が、完璧に作ればおそらくパフォーマンスは最高のモノになるでしょう。C++に比べて倍以上速いかもしれません。
しかし、達人とはいえ、C++で書くよりも20倍の工数が掛かるかもしれません。
ところが、C++で Hello World! ぐらいしかできない人と、アセンブラの達人が同じシステムを手掛けたら、アセンブラの達人の方が少ない工数で仕上げることもあるかもしれません。
その結果で、アセンブラが良いとはならないですね。
それなりにできるもの同士で比べれば、パフォーマンスと工数のトレードオフからC++を選ぶことになるでしょう。
つまり、できない人を持ち出して比べても意味がないわけです（最終決断には、重要なファクターになりますけれど）。
■多数決や、好き嫌いはおかしい
限界値に差がなかったり、トレードオフがあるときは、どちらにフォーカスするかで選択の結果は変わるでしょう。どうしてもパフォーマンスが必要な局面ではアセンブラを選ぶこともあるし、差がなければ最終的に「好き嫌い」になるかもしれません。
しかし、基本的に技術者の選択は、多数決や、好き嫌いがベースになってはおかしいでしょう。
ところが、変に民主主義がいきわたっているためかもしれませんが、技術者であっても「多数決」が正しいと思っている人が非常に多いように思います。
これはつまり、メンテナンスできないという意見について、できるようにスキルを伸ばす選択肢がないのは、結局、多数決になってるじゃないの？ という意味です。
多数決が正しいなら、いまだに「地球は平面で太陽が回っている」ことになるかもしれません。
全世界の人が「頭おかしいのではないか？」と考えても、死刑（家族もひどい目にあう）の危険があっても、地動説を訴えたコペルニクスやガリレオのような人が本当の技術者（科学者）であると思うし、私はそうありたい。
彼らは命を掛けても、「聖書に書いてある」では納得できなかっただけで、もし、自分の理論が、論理的に否定されても納得したでしょう。それが技術者（科学者）というものではないでしょうか？ 私も納得いく反論は常に待っています。
「ちょっとぐらい認めないと士気にかかわる」という御意見も頂きましたが、「地球が回っているのだけれど、聖書には天動説が書いてあるし、太陽が回っててもいいじゃないの」というのは大人の対応ですけれど、技術者の対応じゃないと考えます。
私は相手をひとかどの技術者とみているからこそ、理屈以外は認めるわけにはいきません。「好き嫌い」や「みんな＝多数決」の論を認めるのは、逆に失礼と思っているわけです。
「口角泡を飛ばして議論しても、チャイムがなったら一緒に笑ってご飯を食べに行く」ということが当たり前と思っています。議論の過程において、相手の理論を否定することになっても、相手の人格を否定しているわけではないのですから、相手をひとかどの技術者と見ているからこそ、お互いの理論をぶつけて議論したい。
ガチンコの議論は若い人たちにはキツイらしく（空気が大事なんですね）、「認めてくれない！」と泣き出したり、逃げ出したりする者も出ますけどね……。それでも、私は若い人たちに技術者としての矜持（きょうじ）を持って欲しいのでガチンコであったっていきます。
頑固オヤジです。ハイ。
議論の末に、「出来ない人の多さ＝多数決」や教育コストをもとに、経営者が（短期的な）利益を求め、別の判断をすることは否定しませんが、技術者なら多数決ではなく、ひとまず理屈だけで考えてみればいかがでしょう。
■消えたら終わりだから、多数決は正しい？
もっとも、理論が正しくても消える技術もあります。これを気にしなければならいのが技術者と科学者の違いですね。いつまでも、ベータマックスにこだわるわけにも、VHSにこだわるわけにもいきませんから、なくなる（消える）かどうかは検討しておかなければなりません。
そういう意味では、多数決の部分も無視はできません。
他に、現実的に検討するなら技術を習得するにはコストが掛かり、そのコストが妥当かを検討するには、その技術の息の長さも重要なファクターになります。
■息の長い技術・言語は何か？
私がやってきた言語で考えると、最初はBASIC、C、FORTRANです。
プロとしては Access（VBA+SQL）がスタートでした。
その後、VB、Delphi、Java、ASP、.NET、RPG、PHP、他スクリプト言語。
組み合わせは数々ありますが、その大半でSQLも使ってきました。
私のわずか十数年の技術者人生の中でも、華々しく登場し消えていった言語・ツール・技術はたくさんあります。
Javaのように一旦消えた（Applet）後、復活したもの（Servlet）もあります（笑）
それでも、昔からSQLを嫌う人がいて、SQLをラップするものはたくさん出てます。O/RマッパーやLINQやらイロイロ出てきますけれど、基本的に消えていきました。
なぜ、消えていくのか近々書きますけれど、O/Rマッパーなどは、ごく小さいシステムでしか使えません。
ここ十数年の結果を見れば、最初から最後まで使えているが、一番嫌われ者のSQLというのは皮肉なもので、情報処理技術者試験を見ても、数ある言語の中で唯一専門の試験区分が用意されているのもSQLです。
というわけで、SQLを書くのを補助するツールや、IDEが出てくることはあっても、SQL自身は消えないと私は予想しています。
SQLはデファクトスタンダードです。それならまともに使えるようになったらどうでしょう。
少々の学習コスト・教育コストを掛けても、もとは取れるはずです。
■まとめ
プチ炎上して議論はできましたが、SQLができる人が少ないから（メンテもできないから）、大幅に工数が減ってパフォーマンスがよくっても、採用できない、というありきたりな（10年近く同じ）結果になるのかもしれません。
技術を売っているはずの技術者が「特定の技術ができる人が少ない」と堂々と言ってのけるのが、本当に技術者のすることなのか？ プロなのか？ という私の素人考えの疑問については、やはり解決できなかった。
議論はできましたが、先に外部設計（実装）をアジャイルで行い、後から内部設計（実装）をウォータフォール（でなくてもいいけど）でSQL（ストアドプロシージャ）で行う、という開発手法が取れれば、工数・品質ともに現在のシステムより大幅に改善する。この信念はやっぱり変わりませんでした。
同時に、オフショア（多重請負）などの問題にも切り込んだつもりなのですけれど、そちらには反応がなかったのは残念です。
実現するには、SQLが高いレベルで理解できる技術者が必要、というのは、やはり高すぎる壁なのでしょうか？
なんだかんだと言っても、SQLは最も普及しているデファクトスタンダードの言語ですが、使ってはいるけれど、うわべしか使えないというのは技術者として、本当に正しい判断でしょうか？（結局、いつもこの愚痴で終わることになる）
私自身はそうでもないと思っているので、どうやって習得したらよいのか、今後、ボチボチ書いていけたらと思います。
実践セミナーとかやりたいですね。
私が考えているのは、NDAを締結後、開発に××人日掛かったという帳票などの基本設計書と現状のソースを見せてもらいます。
チューニングしながら（ほぼ作り変え）SQLのテクニックを解説する。
私の用意したテキストでは伝わらないことも多くなるでしょうから、現物で実践的な講義というのを考えています。
見積・打合せ1日、準備1～3日、講義1～2日ぐらいで、つまり、初見で2、3日で修正（というか作り直し）できる自信があるということで、成功報酬でいかがでしょう。冗談のような、本気のような……。
それに大きな成功事例がないと、誰も信じれないというか、見向きもしないという問題もある。論文などを書くのにも絵に描いた餅ではダメですからね。
そこで、エンドユーザの皆様、高くて困っているというプロジェクトはないでしょうか？ 大手の見積の少なくとも半額でやるので、ぜひお願いします（笑）
もちろん、弊社のような小さな会社には依頼できないでしょうけれど、弊社では資金的にも人的にも請けられないのですが、協力会社に元請になれるところはありますので、何卒、よろしくお願いいたします（協力会社っていうぐらいだから上も下もないのよね）。
お問い合わせはinfo@g1sys.co.jpへ。
コメント
ビガー
はじめまして。ビガーと申します。
興味深く拝見しました。
オブジェクト指向の話がプチ炎上されたブログにあがっていましたが、
設計・実装フェーズにのみ触れられており、分析フェーズがないがしろに
なっているため、不毛な議論になっているように感じました。
オブジェクト指向による分析フェーズをお客様の業務を概念クラス図や
アクティビティ図(業務フローなどを定義)、ユースケース図で
静的、動的、機能的な概念(本質)を抑えて、全体像を捉えるフェーズと定義します。
一般的にはこの分析フェーズより上(顧客より)のフェーズを上流と呼んでいる気がします。
分析フェーズの主目的は、業務の中で変わらない(静的)部分と変わる(動的)部分を
整理して、急激な業務変更に対してより柔軟に対応するため、システムの拡張性や
再利用性を高めてトータルのコストを削減することにあると考えています。
まともに分析せずに場当たり的に設計・実装コストを下げられたとしても
ASPやSAASが一般化されつつある実情を踏まえると価値は低くなる一方と思います。
その後の設計・実装・運用フェーズではSQLは強力なツールであると思います。
設計・実装フェーズでは性能を担保しなければならない業務を実現する一つの
解決策として機能しますし、運用フェーズでは不具合等の調査分析では威力を
発揮します。
ちなみにコメントされた皆さんの心情を察するにばかばかしくて返答もしていなかった
と思いますが、SQL程度は皆さん熟知されていると思いますよ。
mcc
すべては
「お問い合わせはinfo@g1sys.co.jpへ。」
のために。
ビガーさん
おはようございます。
上流というところに噛み付いていたのね。
物事の本質を見抜くことが出来る上流の人が読めば文脈で分かると思うけれど、もちろん、分析はある程度終わっている前提で書いています。
私は上流なら分析力があるのは当たり前と思っているので書く必要もないかと。
当然のことを書きすぎると論旨がボケちゃいますよね。
高々数千字の文章を無限に拡大して書くとはできませんので、もっと気楽に読んでいただければと思います。
バッチ処理を選択するかどうか、運用コストと開発コストとパフォーマンス等を考慮して決めるのは上流の仕事ですね。
しかし、十分な知識がないがために無茶苦茶なことを言ってますし、見積も出来ないという現実を見て書いてますけれど……。
横ですが
そう理解した人がいただけで、聖書そのものに天動説は書いてありません。念のため。
インドリ
SQLを使わないってのは無知な人にあわす手段だと思います。
近頃は同じ理屈で、C++を使わない、アセンブラを使わない、C#の参考演算子を使わない、LISPを使わない・・・と【出来名人にあわそう】が本流になっているそうです。
そのうち、オブジェクト指向言語は使わない、DBMSは使わないと非プロ化していくことでしょう（皮肉）
プロなんだから学習して当たり前なのですが、何故かこの業界は全ての局面で、出来ない人／何もしたく無い人が優遇されますよね。
こんな阿呆な業界他にあるのでしょうか？
仕事で何度も「プロならば鍛えろ！」と叫びたい局面がありました。
IT業界では位が上がるごとに無知かしていくのでもうたまりません。
私も健全化を願っています。
横ですが：２
仰るとおり、魔女裁判があったり、地動説→不敬罪だ！みたいな議論があったのは事実です。しかしそれらに聖書的根拠はなく、社会的情勢や政治的要因が生み出した側面が大きいかと思われます。自然科学のルーツに聖書があったり、多くの科学者・技術者にクリスチャンがいるように、聖書そのものは非論理的・非科学的ではないですよ。
> IT業界では位が上がるごとに無知かしていくのでもうたまりません。
> 私も健全化を願っています。
そうなんですけど、賢い人ばかりになったら10億なんて案件でないもの。
結果、我々の生活を守ってくれているのかもしれません（皮肉）
健全化したらITドカタと揶揄される人はいなくなって、デスマもなくなるでしょう。
しかし、ついて行けなかったITドカタ達は、どうやって飯喰うの？ってことになるかもしれません。そういう人を救うために、客からぼったくるというのは、許される理屈ではありませんから、健全化すべきです。
> 社会的情勢や政治的要因が生み出した側面が大きいかと
でしょうね。
腐れ教皇とか、一杯出てますからね。
イスラム教も、キリスト教も、ユダヤ教も本質的には「いがみ合え」なんて教えはないはずなんですけれど、さんざん、歪められて、政治的に利用されていますからね。
悲しいことです。
インドリ
SQLから逃げないなどのプロとしての当たり前の事を進めようとすれば、有名な人月単価問題に突き当たると思うのですが、生島さんはどう思われますか？
インドリ
記述不足だったので追記します。
何故人月単価問題が浮上するのかといいますと、人月単価は効率が悪いほど儲かるからです。
儲かるならば経営者はそっちを優先するでしょう。
そうなれば、結果として「SQLは効率が良く利益を下げるから逆に使わせない」となりかねません。
この次は、Martin Fowlerにちょっかいを2回か3回に渡って出して行きます（笑）
人月単価はいずれ書きたいと思っています。
昔は、デスマ大好き、定時まで仕事しないで生活残業！とか。
3ヶ月デスマに付き合って1ヶ月バカンス。
ってデスマ大好きな人も大勢いましたし、派遣中心の中小の社長は、デスマを望んで、デスマに耐えれる技術者を望んでいる人もいないとは言えません。
大手SIerはデスマはイヤでしょうが、見積が下がるのは喜びませんね。
ここの解は「下がった分オフショアをやめましょう！」
何ですけど、伝わるわけないか……。
しかし、こういうご時勢ですから「チャンス！」と思っています。
変わらざるを得なくなるでしょう。
ハード・ネットワーク・セキュリティ・DB・言語の内、複数の専門性がないと淘汰されてしまう、というのは、すぐそばまで来ている流れだと思っています。
tor
サーバ／ネットワーク屋なので畑違いですが、とても面白く読ませていただきました。（以下、用語等を知らないので拙いですが、お目汚しご容赦ください）
要件と設計に合わせた環境を構築しても、想定より遥かに低いパフォーマンスなシステムや、些細な仕様変更で大幅に工数が増えデスマ来訪など多々見てきました。
MRTG的なものを自作するケースも多いため、多少の言語（JAVAやSQL）を使います。
MRTGが負荷になっては本末転倒なので、整理され効率化されたI/Oがサーバの負荷低減に大きいと結論付け、SNMP取得値はDBに格納することになるから、それならSQLで何をどこまでできるか？を最初に考えるようになりました。
JACAやCはできない部分を補いHTMLにアウトプットするためだけ、みたいな。
その程度なレベルの私からみても拙いSQL、その結果、JAVAで無駄な処理を行っていることが原因でパフォーマンスや工数がネガティブになるケースが非常に多いです。
今のサーバはパフォーマンスが良いので、後処理でどうにでもなると考えてる人が多いんですよね。
そこをツッコムと「他人の畑に首突っ込むな」と言われます（笑
そういう方々の座右の銘は「動くシステムが良いシステム」だったりしています。
torさん
ありがとうございます。
> その程度なレベルの私からみても拙いSQL、その結果、JAVAで無駄な
> 処理を行っていることが原因でパフォーマンスや工数がネガティブに
> なるケースが非常に多いです。
これは人月商売をしている営業にも問題があります。
Javaのシステム、Struts経験者などなどの条件で集めるから。
RubyのシステムでもJavaの経験があればできるし、やらせるべきだと私は思っています。オブジェクト指向（手続き型も）とSQLは概念が違いすぎるので、第一印象で変なイメージを持つと、非常に高い壁が出来てしまいます。
人月の商売をしている営業は、よく判ってないから、Javaなどの経験ばかりを見てマッチングしますから、そちらに処理が偏るのも無理がないのです。
近々、リライトしますが、Javaで処理すると以下のようになってしまいます。
http://www.g1sys.co.jp/column/_2006_11_10.html
Javaで処理しているのを見ると、私の頭の中で営業マンが駆け回ります（笑）
tekito
大筋の話としては納得いくものなのですが、ひとつだけ違和感を持つところが。
SQLをラップするO/RマッパーもLINQもつい最近普及し始めたもので、消えていった技術の例としてあげるのは不適当では？
こう反論したいのは、私がSQL構文を苦手としていることとは無関係ではないかもしれませんが、後々これらの技術が使えない例を挙げるにしても、消えていった技術としてこれらをあげるのは適当ではないでしょう。
tekito さん
ありがとうございます。
確かに、消えていったは言い過ぎかもしれません。
実は、寂しがり屋なので突っ込んで欲しくて書きました。
ご理解いただき、ありがとうございます。
O/Rマッパーにしても、LINQにしても、思想的にSQLが嫌いだから、難しいから、という思いで作られているものは、成功することはありません。
使う側としても、O/Rマッパーを使って「SQLを書かなくても良い」って考える人はすぐに痛い目に会うでしょう。
言語的に考えると、
第１世代 マシン語
第２世代 アセンブラ
第３世代 FORTLAN・COBOL・C
第３．５世代 オブジェクト指向言語
第４世代 SQL
と考えています。
現在、一番高級な（人間＝自然言語に近い）のはSQLだと私は考えています。
つまり、３．５世代までは分岐もループ（つまり、アルゴリズム）も要るで低級なのです。
どんな言語で書いても、最終的にはマシン語に翻訳（コンパイル）しないと動かないのですけれど、SQLは、その後、C++などで書かれたプログラムで実行されるわけですから…。
３．５世代（O/Rマッパー）→ 第４世代（SQL）→ ３（３．５）世代（DBエンジン）→ 第１世代（マシン語）
と実行されるわけで、低級言語が高級言語に翻訳するというのは、そもそもテクノロジーの進化として間違っていて、SQLを少しでも分かる人間なら、３．５世代（O/Rマッパー）に頼るのではなく、いきなり第４世代（SQL）で書いた方が明らかに効率的なのです。
現実に３．５世代（O/Rマッパー）は人間を超えれないから、パフォーマンスの問題が起きます。（小さい仕組みでは問題は顕在化しないけれど）
言語の世代を逆に見れば、新世代の言語を使えば人間の能力を超えるから使えるのです。
Cで書いても、Javaで書いても、最終は（中間ソース）→ アセンブラ → マシン語
と翻訳されて実行されるわけですから。
LINQにしても、内部的に第４世代のSQLを生成しているならば、人間が書いた方が効率的なのは明らかです。
O/Rマッパーが生まれること自体、皆さん、SQLを嫌いすぎで、どこか勘違いがあるでしょう。それは、逆転の発想として面白いけれど、論理的におかしいです。
ただ、正直に言ってO/Rマッパーは使ったことはないのですけれど、ロジックをストアドに寄せた後にも使えますよね。
オブジェクト指向とSQLの間には、確実にギャップがありながら組合わせて使うことになりますから、SQLを理解した人がそのギャップを埋めるために使うツールとして考えると、十分に使えるとは思います。
ギャップがあって、嫌われるのは理解してますけれど、食わず嫌いはやめようよ。
というのを言いたいわけです。
G.O.R.N
LINQ を SQL が嫌いだからっちゅう観点で語るのは失当じゃないかなと思います。元々、そのために技術開発された類いのものではないのは Cωからの来歴を見れば明らかなので、恐らく源流になったであろう Microsoft Research での一連の研究プロジェクトを見てもそんなことは書いていないので。そういう意味では SQL が嫌いだから LINQ を使うという発想自体が根本的に適用分野を間違っているんでしょう。その意味では、Language INtegrated Query という名称自体が本質からずれたマーケティング用語のような気がします。
MSR の論文群をサーベイする限り、複数の関数型言語に関する研究が走っているようです。関数型言語の多くは基本的にループを明示的には書かず、末尾再帰などの仕掛けで最適化で実行時のコードを改良していく戦略を採ります。恐らく、こういう仕組みを C#、VB に取り込むために LINQ という実装があり、LINQ to SQL は実際、成果物が見せやすくお金を取りやすいから見えてるにすぎないと認識しています。実際、MSR の方は直接 SQL に変換される LINQ to SQL に開発リソースは回っていなくて、ループを消して並列に展開する PLINQ やクエリを複数のサーバに同時に分散して投入する Dryad LINQ にリソースを割いていますね。
まあ、成果物がないと研究資金も出ませんしね。
G.O.R.N さん
おはようございます。
もちろん、LINQはSQLのために作られたのではないことはよく理解しています。
しかし、私自身はRDBMSを使うのにLINQを使うことはないので本質的には理解できないのですが、多くのブログなどで書かれていることを読むと、使う側の思想は「これでSQLを覚えなくてよい」という感覚がほとんどのように思います。
SQLについて書いている文章で、LINQについてはおまけなのでスルーしてもらえればと思います。
個人的には、LINQはまだまだ中途半端な気がしますし、LINQ to SQLについては使っても実質的にどんなメリットが出るのか理解できません。
****
SQLが出来るのに越したことは無いですよね。
私はSQLと格闘することにも情熱を燃やす系の人間ですが、
LINQは結構好きです。
色々メンドクサイコードを一々書かなくて良いので。
（設定はする訳ですけども）
たとえば、データを取り出してぐるぐる回しながら、
何かをやる場合、C#だと、
using(var dc = new DataContext){
foreach(var entity in dc.Entities)
{
// 何かやる
}
}
これだけで完結します。スッキリします。
O/Rマッピングを使うか使わないかは分かれるところですね。
※2015/2/25 コメント投稿者からの依頼により、投稿者名を伏せ字にしました（エンジニアライフ事務局）
**** さん
こんばんは。
LINQは……。
> using(var dc = new DataContext){
> foreach(var entity in dc.Entities)
> {
> // 何かやる
> }
> }
は、
// 何かやる
が処理の大半ですから、他のものでも大差はないように思うのですけれど…。
私は本質的には理解をしてないのでスルーしてください。
なかじまゆうじ
> 個人的には、LINQはまだまだ中途半端な気がしますし、LINQ to SQLについては使っても実質的にどんなメリットが出るのか理解できません。
「おまけ」に喰いつくと、LINQは元々「どんなデータソースにもSQLでアクセスしよう」な方向性を持ったものだと思いますので、DBMSにLINQでアクセスしても何も面白くないと思いますよ。
LINQ to SQLは、これから出てくる他のLINQが「このインタフェースにあわせて作る」ためと、「SQL文に対してもビルド時に構文エラーチェックしたい」という欲求を満たすことくらいにしか存在価値はありませんから。
それはそうと、生島さんは「データモデル（テーブルレイアウト）の変更を含む仕様変更に対する、生産性と品質の向上」について、どのようにお考えでしょうか。
> 「どんなデータソースにもSQLでアクセスしよう」な方向性を持った
> ものだと思いますので、DBMSにLINQでアクセスしても何も面白くないと
> 思いますよ。
そのとおりだと思います。
RDBMS以外にアクセスすることが多い人は使ったらいいと思います。
私は、業務上、RDBMS以外にアクセスすることは比率的に考えると非常に少ないので、騒ぐほどの物でもない。
よく知りませんが、必ず実行計画を見るという人は、LINQが生成したSQLを捕まえて、その実行計画を見るってことになるのでしょうか？
それって、はてしなく無駄だと思うのです。
> 「SQL文に対してもビルド時に構文エラーチェックしたい」
そのためのストアドプロシージャじゃないですか？
> 「データモデル（テーブルレイアウト）の変更を含む仕様変更に対する、
> 生産性と品質の向上」について、どのようにお考えでしょうか。
仕様変更を防ぐためにテーブル設計を最後に廻すわけで、その結果、テーブル設計もしっかりしたものになりますから、変更にも強くなりますよ。
弊社で中小企業の基幹システムをすべてストアドプロシージャで作りましたが、内部でループしている5ヶ所ぐらいです。
他は基本的に１文のSQLにパラメータを与えているだけです。
そうなると、SQLが判る技術者をそろえた場合、変更には強くなります。
SQLが判らない人には手におえなくなりますけどね。
なかじまゆうじ
> 仕様変更を防ぐためにテーブル設計を最後に廻すわけで、その結果、テーブル設計もしっかりしたものになりますから、変更にも強くなりますよ。
いや、そうじゃなくて、一旦システムが完成して1年後とかに、「業務要件が変わったから仕様を変更して」と言われた場合の話です。
もちろん、既存のテーブルに影響が無ければ良いのですが、場合によっては一部のデータモデルを変更せざるを得ない状況もある訳で、そんなときの話です。
このへん、説明が難しいのですけれど、500テーブルも作ってしまうようだと、どんな変更でも非常に重くなると思います。
きっちりテーブル設計していれば、変更はある程度予想出来ますし、SQLで処理した方が変更は楽です。
もっとも、できない人にとっては手に負えなくなります。
できない人が反対するから実現できない。
結局、これが答えで、できる人が増えれば問題は解決します。
増えればですけれど。
なかじまゆうじ
？？
> それはそうと、生島さんは「データモデル（テーブルレイアウト）の変更を含む仕様変更に対する、生産性と品質の向上」について、どのようにお考えでしょうか。
という自分の質問に対する答えが、
> 結局、これが答えで、できる人が増えれば問題は解決します。
> 増えればですけれど。
ということでしょうか？
結局ですね、
http://el.jibun.atmarkit.co.jp/g1sys/2009/01/sql-2b18.html
この辺が会話のペースで出来ていれば、テーブル変更があっても、ロジックは会話のペースで脳内で直して、清書・チューニングするコストぐらいで直せるんです。
もちろん、テーブルの変更とデータの移行等は、ロジックがどちらにあってもコストは同じはずですけれど、SQLができない人がデータ移行するととてつもなく時間がかかりますよね。
つまり、できる人を増やすしかないってことです。
なかじまゆうじさんは、できる方の人ですけれど、できない人に合わせる癖がついていませんか？できない人が作った設計を正しいものとして話してませんか？
それは、現実的ですけれど、悲しいなと思います。
なかじまゆうじ
つまり、生島さんは「データモデル（テーブルレイアウト）の変更を含む仕様変更に対する、生産性と品質の向上」のためには、「SQLができる人を増やすしかない」という人材育成だけに頼った考えをお持ちということですね。
もちろん、できる人が増えれば、それだけ質も上がります。自分もそれを望んでいます。
でも、技術者として、技術でそれを解決する方策についてはお考えにならないのでしょうか。
変更についてもUIな得意な人がUIについて先ず仕様を固める。
その間、ダミーのストアドプロシージャを使います。
DBが分かる人が内部を担当する。
分け方が上下じゃなく外内と話しているのですけどね。
技術者としては、オブジェクト指向が判らないという人をどう使えば良いか、というのと同じ問いでしょう？
それに技術的に答えがあるのでしょうか？
一般的にオブジェクト指向などに比べてSQLは教育コストを掛けなさすぎです。
なかじまゆうじ
> 技術者としては、オブジェクト指向が判らないという人をどう使えば良いか、というのと同じ問いでしょう？
> それに技術的に答えがあるのでしょうか？
あります。
もちろん完全な（ベストな）答えは見つかっていませんが、それを模索している方はたくさんいらっしゃいます。
そして、その答えの1つがフレームワークという考え方に含まれています。
なかじまゆうじ
あっ、上のは「オブジェクト指向が判らないという人をどう使えば良いか」の話です。
では、フレームワークを利用した上で、ダミーのストアドプロシージャを利用すれば先にUIを完璧に作れます。
そんなことはどうでもよく、つまりフレームワークが云々ではなく、外部（つまりユーザが理解できる部分）を完璧に先に作るべきで、内部は後回しで良いといってるわけです。
外部と内部は、必要なスキルが違うのですけれど、フレームワークが解決するという人は、外部と内部を一緒にしたいという概念ですから……。
私から見れば、特性を活かせていないと考えています。