こんにちは。

初級シスアドと言っても馬鹿に出来ないですよね。

私は見事に落ちました。

情報処理二種を取っていたので「楽勝だよ」って気分だったのでしょうね。
試験受けるまでどんな内容なのかも判ってませんでしたから。

ヴァンさん、こんばんは。

初級シスアドも、合格するための勉強でなく、内容を完璧に理解していたら相当な戦力です。

私も、実はシステムアナリスト落ちました。
普段、字を書かないから、ワープロがなかったら絶対に無理と分かりました。

バックスペース使いまくりで推敲する癖がついているから……、午後の記述問題で時間が足りずそれでもギリいけただろうと思ったのに5点足らなかった。

小論文はそこそこ書けていると思ったんだけどな、まぁ、私が試験官なら「字が汚い」で落とすけどね

こんばんわ。

私は密かに第一回シスアド試験（今のように初級とかに分かれる前）の合格者だったりします。ですが開発側ですので、全く役に立っていませんが。

SQLを基本スキルとして４種に業務範囲を分割されるパターンを提示されていますが、個人的な気持ちとしては、UI実装、ビジネス層（DB含む）、UXデザイナと分けたいところですね。設計としては、ビジネス層とそれ以外でもなんとかなるのかな、と思います。そして生島さんの言われる通りビジネス層については設計も実装も、SQL等現行におけるメジャースキルは必須だと思います。

業務システムを作成するのにSQLはまだまだ現役でしょうし、それを用いるビジネス層こそが「システムの核」となるはずでしょうから、この部分の有スキル者というのを何とか育てていきたいものですね。

私の勤める会社でも・・・まぁ・・・なんですよ。
自分のスキルも上手いこと教えられないのが本当に歯がゆいというか。

Ahfさん、こんばんは。

弊社は、Webのデザインもやっていて、全くシステムと関係ない社員もいます。

> ４種に業務範囲を分割されるパターンを提示されていますが、個人的な気持ち
>としては、UI実装、ビジネス層（DB含む）、UXデザイナと分けたいところですね。

その基準で、私のイメージで考えると
　　UXデザイナ
　　UI実装
　　UIビジネスロジック
　　DB実装
　　DBビジネスロジック

の５層なのかも知れませが、そんなに違わないと思います。

こんばんは。

SQLは避けて通りたいと思っているプログラマです。
その立場でコメントしてみたいと思います。

SQLそのものが難しいと言っている人はあまりいないと思うのですよ。
だから、簡単なのになんで覚えない、と連呼しても、あまり意味がないと思います。

じゃあなぜ避けて通りたいかというと、説明しにくいところはあるのですが。
手続き型というより、オブジェクト指向と相性が悪いのではないでしょうか。

オブジェクト指向は、この世のすべてのものはオブジェクト、とか言っていることからもわかるように、
オブジェクト指向の考えかただけで頭を切り替えずに、設計について考えたりプログラムの修正を行ったりすることができる、
という利点があります。

どうしても他の考えが必要な時はそれを隠ぺいして、
それを扱うときだけ頭を切り替えて、普段は考えなくてもいいようにします。

ところが、SQLにロジックが書かれていると、それができなくなるのですよね。
SQLを扱うたびにオブジェクト指向から頭を切り替えるか、
SQLの部分はブラックボックスとして普段は考えないか、
どちらかが必要になってきます。

これが、業務ロジックを考える上で、非常に邪魔に感じるのです。
ブラックボックスになってしまうのもいやなので、別の人間に任せるというのはあまり解決にならないでしょう。
だから、せめてO/Rマッピングで隠ぺいしようとか、そういう方向に向かいたくなるのです。

と。
ここまで書いてきましたが。
現実問題として、SQLを使うことでパフォーマンスを上げねばならないことはあるわけで、
今回の例に挙げられているくらいのSQLは理解できないとまずいんじゃないか、とは思いますね。
このくらいならO/Rマッピングツールとか使わなくても隠ぺいできる範囲にありそうですし。

たしか新人研修で２日ほどSQLをやった時点で、
そのくらいは読めるようになっていました。
忘れているというのもあるかもしれませんが、半日あれば思い出せるんじゃないでしょうか。

業務ロジックは全部SQLで、とか言われるとちょっと反対してくなりますが、
今回の例に挙げられた程度のSQLについていえば、話が違うと思います。

SQLはデータ中心アプローチですが、オブジェクト指向はそもそもプロセス＋データです。
オブジェクト指向をかじっている人で、その点を理解されていない人も見受けられますが、SQLを否定すると言う事は、オブジェクト指向の要素を否定する行為です。
オブジェクト指向プログラミングで、if文などの構造化プログラミングの要素を避けますか？
使うものは全て使うのがプロです。
ちなみにオブジェクト指向に詳しい人ほど、データ中心アプローチも構造化設計（プロセス中心主義）も理解しています。
オブジェクト指向を間違って受け取っている人が多いような気がします。

記事について
同感です。今のIT業界は官僚組織と同じですね。
鍛錬するよりも如何にサボって利益を得るかを考えて行動しています。
それはお客様を無視した詐欺行為です。
騙されている事にお客様が早く気付いてほしいです。

誤：使うものは全て使うのがプロです。
正：使えるものは全て使うのがプロです。

おはようございます。
レスありがとうございます。

>全部オブジェクト指向でできない以上、どこかに線を引かないといけない。それが担当者レベルの線引きにさせるべきでないし、線を引くなら担当者を分けるべきだと言っているわけです。

「言っているわけです。」という話をするなら、私はSQLをろくろく使わない開発者も怠惰や無能だからそういっているわけではない、と言っているわけなのですけれどね。

>プロなら成果物にプライドを持つべきです。

もちろんです。自分の意見に合わないことをいう人はプライドがないからそんな意見を言うのだ、という判断は、争いのもとになるだけで、あまりよろしくないのではないでしょうか？

>普段書いている実装者（PG）はそれなりに線引きができますが、コーディングをしない設計者（SE）が大勢いて、そいつらが先に線引きするのでしょう。
>それがおかしいと言ってるのです。

これはおかしいと思いますね。
なんか理由はあるのでしょうが、少なくとも私は弁護できないので
そうだそうだおかしいぞ、で済ませておきます。

>すべてストアドプロシージャにすれば線引きの基準も明確になるし、パフォーマンスも良くなる、担当者も分けれるし、工数もへる。

判断基準がおかしいです。
自分の案のメリットだけ連呼して、だから採用すべきだ、という判断ができるなら、
たいていの案は採用すべきということになってしまうでしょう。

デメリットも検討して、メリットと比べ、だからメリットが多い場合についてはという条件付きで採用すべきだ、
という判断をしないといけないのではないでしょうか？

デメリットを説明しようと思いましたが、その前に質問です。
デメリットはどういうものがあると思いますか？
また、どのような場合にはデメリットが大きくなるので、生島さんの案は採用できない、と思いますか？
そういう観点で話さないと、お互いに自分の意見のメリットばかりを連呼するばかりで、
水掛け論以外にはなりようがないと思うので。
まず質問です。

私は生島さんの案を採用するべき状況はあると判断しました。
残念ながら、そんなに多いとは思っていないのですが、
今後生島さんの話をもっと聞くことにより、それが増えるとは思います。

インドリさん、こんにちは。

オブジェクト指向だろうが、もうしばらくSQLを使わざるを得ないでしょうからね。
もう少し勉強してほしいものですね。

がるです。

> SQLは、実際の現場で極めて広範囲に使われている技術ではないのか？
SQLを「全く使っていない」現場というのは、比較的少ないと思うのですが。
「どこまで使っているか」というあたりには、現場毎に非常に差違があるのではないかと思っています。
例えば以前「SQL使い物にならない」といわれた現場では「秒間で数10万～数百万以上程度の単純な検索に耐えられる性能」を要求されていました。且つreturnが確か…100ミリセックだか200ミリセックだか未満、とかいう要求があったと記憶しています(えぇまぁその分、割合無茶なハードウェアスペックは頂戴できたのですが)。
こういう要求ですと、当然ながら「SQLでは非常に困難」なわけで。
「一つの技術」としては、SQL(というかRDB)は大変に優れた思想ですし、便利で面白いと思うのですが。
ただ「どこにいっても使えるか」と聞かれると、私は「銀の弾丸は存在しない」と考えています。
どちらかというと。RDBは「複雑で、比較的高頻度にコロコロ変わる厄介な要求を片付ける」のに適している一方で「比較的単純な作業を軽量高速に、大量に処理する」のには不向きだと思っています。あとスケールアウトさせたい時にも、複合したSQLは正直扱いにくいですね。
そのあたりの「長短」を見極めた上で「適切なタイミングでの適用」が大切なのではないでしょうか？

まぁおそらく。
私は「データストアシステム」が欲しい環境に居る事が多く(Web系システムの、特にfront周りはその傾向が非常に強いです)、一方で生島勘富さんの環境は「リレーショナルデータベース、という集合論」が重要な環境(いわゆる「業務系」が、この傾向が強いとよく耳にします)にいらっしゃる事が多い、という事なのではないでしょうか。

>RDBMSにデータを入れる以上、インピーダンスミスマッチは必ずあって、それをどう解決するかです。

わかりやすく解決する方法として、O/Rマッピングツールが存在します。
あるのに使わない理由は何でしょうか？

>できる限りオブジェクト指向言語側で解決して、遅かったらSQLで考え直しましょう。ってのは無駄以外の何モノでもないでしょう。

なぜ無駄ですか？
オブジェクト指向の利点はほとんど受けることができるわけですが。

>その結果は、素人にメンテできるようにSQLのスキルを求めておきながら、SQLにおいて素人レベル以下のものを納品することにしかなりようがないのです。

>それを指して、「プライドがあるのか」って言ってるわけです。

オブジェクト指向設計として素人以下のものを納品することは、
プライドを持った技術者の行為なのですか？

自分の持っている技術にのみプライドを持っても仕方ないでしょうに。
「納品物に」プライドを持つべきなのではないですか？

>工数、パフォーマンスともにSQLの方に分があります。

これについてはそうですね。
工数については、設計変更を抑えることができれば、という条件付きかもしれませんが。

>素人にメンテできるように国家試験まで作っているわけですから、できる人にとっては保守性もSQLの方が上です。

国家試験になっていることと、保守性があることとの因果関係言ってください。

SQLができてオブジェクト指向が素人レベルの人にとっては、SQLのほうが保守性があるでしょう。
だからといって、オブジェクト指向がわからない素人が作ったものを納入する理由はありません。
社員に、O/Rマッピングツールも使いこなせないような人しかいないからと言って、素人レベルのものを納入するのはどうかと思います。

とまあ、私としてはここまで決めつけるのは何だと思いますけどね。
生島さんの論法でいくとこうなりそう。

んー。
相手をけなすことばかり考えるのではなく、
議論することを考えませんか？
相手の意見を一蹴するだけでは、意見を受け入れてもらうことはできないと思いますよ。
自分に絶対権限がある場合ならそれでも通るのでしょうが。

一プログラマーである私より、経営者である生島さんのほうが、１０００倍は交渉力があると思うのですが。
ここで話を聞く限りにおいては、なんかそうは思えなくなってきています。

これだけSQLを押すからには、パフォーマンス面が原因で工数を食いつぶした経験がたくさんあるのかなあ、と話を始める前は思っていましたが。
話を聞いていると、むしろそういう客観的な判断はしていないのではないかなあ、と思えてきました。

説得力という面ではマイナスの効果をあげているのではないでしょうか？
もうちょっと客観的に、SQLが有利な点について述べたほうが、少なくともここでは説得力があると思うのですが。

基本的には私は、技術者として今後アーキテクチャの判断をする必要が出てきたときに、
ここはストアドプロシージャで行くべき、という局面について学習するべく話しているつもりです。
客観的に、どういうときにそういえるのか教えていただけませんか？

がるさん、こんにちは。

基本、SIerの立場で書いているので申し訳ない。
データストアだけが欲しいなら、そもそも、RDBMSを使うべきではないでしょう。
例えば、Googleの検索エンジンを作るのにRDBMSなんか使ったら大馬鹿ものですよね。
データストア用は良いものがなさそうですが、RDBMSほどは需要はないからでしょうね。
Googleが自社で使っているものを出してくれたら良いのですが、アレって完全に特化しちゃっているのでしょうね。

こんばんは。

>すみませんが、1年ぐらい同じことを書き続けているので、過去に書いたことはできるだけ重複しないようにしたいと考えています。でも、結局、同じテーマで書いているので重複だらけなのですけれど、抜けているところがあるのは申し訳ないです。

すみません。
記事に目は通していましたが、その後の議論までは読んでないです。

>一般的な方が保守はしやすいのは常識と言えると思います。

この場合の保守性というのは、教育コストがかからない、という意味ですか？

オブジェクト指向プログラムの保守性が高いというのは、
もっともっと高レベルに保守性が高いことを言っていると思います。
どんどん機能変更があってもついていけるとか。
いや、オブジェクト指向を使いこなしていないと無理ですが。

>簡単には、例えば、

いや、具体例をあげていうなら、こちらも.NETを使って同じくらい楽にできそうな方針は挙げられますが。

生島さんは、JavaやC#を利用したアーキテクチャもSQLと同じくらい精通していて、
そのうえで、スタブなどを利用するにはSQLを利用するのが最もコストがかからない、と言っているのですか？

もしそうでないなら、JavaでうまくいかないのはJava技術者の腕が悪いせいでしょう。
生島さんのようなSQLでのアーキテクチャに特化した人間がいて、それ以外に特化した人間がいない場合にしか、通用しない話だと思います。

>Java（オブジェクト指向）側は実はアジャイルの方が向くし、SQL側はウォータフォールの方が向くのです。一緒にしているから問題が起きる。

アジャイルなんてものが有名になったのは、オブジェクト指向の歴史の中でもごく最近でしょう。

ウォーターフォールでは不足でアジャイルに向いている仕事が徐々に増えてきたから、
それに向かないSQLがだんだん見はなされてきた。
という順番ではないのですか？

がるです。

> 例えば、Googleの検索エンジンを作るのにRDBMSなんか使ったら大馬鹿ものですよね。
おそらく、性能要求をたたき出すのは極めて至難なのではなかろうか、と思います。
ちなみに純粋に興味から、なのですが。例えば生島勘富なら「かかるコストは高いが恐らくは可能そうな感触」ですか？ それとも「RDBという概念に対する現在の実装では、おそらく無理だと思われる」感じですか？

> データストア用は良いものがなさそうですが、RDBMSほどは需要はないからでしょうね。
最近ですと、KVSという形で良いものが出てきつつありますね。
memcacheあたりは、大分とメジャーでもありますし人気もあると思います。

> Googleが自社で使っているものを出してくれたら良いのですが、アレって完全に特化しちゃっているのでしょうね。
BigTableでしたら、大分と出回ってきてますね。
特化というほどでもなく、BigTableもまた基本は「KVS」ですので。案外に使い勝手はよいと個人的には感じています。

あと。
ほかの方とのやり取りの横やりになってしまうようで恐縮なのですが。
> > 国家試験になっていることと、保守性があることとの因果関係言ってください。
> 高校生でも資格者が居るほどの一般的なものであるから。
こちらのやり取りに少々興味を持ちました。
生島勘富さんのおっしゃる「保守性」とは、具体的にはどんな内容を示されてるのでしょうか？
まりもさんとのやり取りを拝見していて、何となく一つ、そのあたりに齟齬があるのかなぁ？ と感じたのと、合わせて(業務で色々考えさせられる事象がある、などの理由もありまして)、保守性という言葉を、今一度深く考察してみたいとちょうど考えていたので。
よろしければ生島勘富さんの私見なりをうかがえれば、と思いました。

こんばんは。

>C#ぐらいなら、リンクのグリッドコントロールを作るぐらいは精通してますけど……。こんなの楽勝って言うのなら、今の倍の給料を出すので是非来てください（笑）

どうかな。
楽勝ではないかな。
がんばればできる気はしますが。
仕事として見積もりして納期を設定して、というのを責任を持ってやれと言われると自信ないですね。
ＵＩ関連は自動テストも難しいですし。

しかし。
現在話題になっているオブジェクト指向設計の話とは、
かなり離れた話になっているように思えますが。
オブジェクト指向言語を使って業務ロジックのスタブをどうこうとか、
そういう経験はあまりない、と判断してよろしいでしょうか？

>まりもさんのレベルはうかがい知れないけれど、相当に経験があるのですかね？

どうなのでしょうかね。
基本的には下っ端プログラマですが。

難しいことはたまにしかやらせてもらってませんが、
やらせてもらった時には結構できているような。

C#のクラス設計とコメントを全部コードから読み取って、仕様書を出力するとかいうのが一番難しい仕事だったかな。
上司の簡単な指示を受けて、暴走して作りこんでしまったのですが。
具体的な指示がある時は簡単な単純作業が主なのが困りもの。

DB関連だと、OracleがTableAdapterに非対応だったので、TableAdapter似た使い勝手のものを自作したりとかしました。

あとまあ、個人的な勉強の成果とかをこんな感じで挙げていたりしますが。
まあ大したものはないですが。
http://sourceforge.jp/projects/marimo/
そういや最新版リリースしてなかったが。

まあ技術自慢とかしあっていても意味はないと思います。
総合的な経験や特にSQLに関して言えば、生島さんにかなり劣っているのは間違いないです。
ただ、オブジェクト指向について私が理解していることで、
生島さんの論から漏れていると思われるところがあるので、それを指摘しているつもりです。

オブジェクト指向というのは、
複雑でわかりにくい業務ロジックを、
わかりやすく整理した形でプログラムにできるのが利点の一つで。

だから、複雑な業務ロジックをころころ修正することができるので、
アジャイルに向いているというのもあるし、
コンピュータのプログラムに求められることは徐々に複雑になってきているので、
今後どんどんオブジェクト指向が有利になっていくと思います。

SQLはそのへんについては苦手なのではないでしょうか。
ロジックをすべてSQLに入れたものは経験したことがないですが、
一部のロジックがSQLに入っているので修正のために工数がかかりまくって仕方なかったことは何度か経験しています。

また、オブジェクト指向の軽視はよく経験していまして。
これで修正が難しくなって大変苦労することも多いです。
しかもその状況が続いて、オブジェクト指向は天才がやるものだ、とか言い出すような同僚に囲まれて今後どうすればよいものやら。
修正が難しいコードがどんどん量産されていきます。

でまあ、こういう経験からすると、
生島さんの案は手放しで賛成できない、という気はするのです。
業務ロジックをきちんとオブジェクト指向を利用して作るという経験は重要で貴重です。

もちろん、生島さんの方法が向いている場面も多々あり、
その場合に採用するのは当然だとは思いますが。

>まぁ、ずーっとそんな糞ガキンチョに多数決で負けてますので許してください。

基本的に、SQLを勉強しないのは勉強不足でプロとしてどうかと思う、
という意見さえひっこめていただければほぼ苦情はないんですけどね。

ところで。折衷案としてLINQはどうでしょう。
SQLと同じような記法でかけて、
SQLに近いパフォーマンスが出せます。
（というかSQLに直訳してDBに投げてくれる。)

それでいて、結果セットをオブジェクトで受け取れるので、
オブジェクト指向との相性もかなりあり。
LINQの勉強なら自然にできるのです。

がるさん、おはようございます。

GoogleをSQLで？できなくないけれど、

「あ」から始まるキーワードサーバ
　　「ああ」から始まるテーブル
　　「あい」から始まるテーブル
　　……
「い」から始まるキーワードサーバ
……

キーワードサーバ、テーブルを管理するサーバを用意しておけば、お手製クラスタですけれど、無限に拡張はできますね。論理上は可能なハズですけれど、そんな数のリンクDBを使ったことがないので、実際に動くかは知らない。

1テーブルを1～2ギガぐらいに抑えてやらないときついでしょうね。
データはあらかじめスコア計算を終わらせて、スコアー順に並べておくでしょう。キーワードの件数も別テーブルに入れて、先に計算して保存しておきますな。
まず、キーワードを切りますね。

「生島勘富」→ 「生島」「勘富」

最初ヒット数を取って、
「生島」 200000件
「勘富」 2000件

少ない「勘富」から、多い方の「生島」とURLでマッチングして、ヒットがどれぐらいか件数を見ます。表示に必要な件数まで出力できれば、そこまでのヒット率から約何件ってのを計算します。

他に、キーワード数とヒット数とその差によって、スキャンの方法を何種類か作って……。

もともと、RDBMSは複雑なことを簡単にできるように設計されていますから、単機能には向かない。RDBMSはオーバーヘッドが大きすぎです。

単機能になる場合、RDBMSでは不要なオーバーヘッドの分無駄ですから、ハードは今のGoogleの数～10倍ぐらい要るんじゃないかな？

間違った情報が流れているので書きます。
DBもアジャイル開発出来ます。
SQLも所詮コードですし、スクリプトを使えば自動テストも出来ます。
それに、SQLもオブジェクト指向として捉えられます。
その証拠にSQL1999で対応済みです。
しつこいようですが、オブジェクト指向を知っているのであれば、
SQLもシステムという一つのオブジェクトのデータとして捉えられます。
私はその様にしてシステム全体を設計＆実装しています。
あと、集合理論からオブジェクト指向とSQLを捉える事が可能です。
オブジェクト指向を誤解している人が多いですね。
欧米の優れたオブジェクト指向使いたちはSQLを忌避するなんて愚かな事しません。
何かの技術から逃げるのはプロではありません。
好き嫌いで技術を習得せず、他者に迷惑をかけるのであれば辞めてほしいです。
好き嫌いで通るのは趣味だけです。

こんにちは。
また短くまとめてきましたな。

>SQLで書いたのが直すのに時間が掛かるならスキル不足です。
>もちろん、業務ロジックをオブジェクト指向で書いたこともあります。SQLでやるよりも、スタブにも時間が掛かっています。

客観的に見て、
スタブに関する機能はオブジェクト指向言語のほうが豊富ですよね。
ロジックを構造的にまとめるための機能もオブジェクト指向言語のほうが豊富です。

生島さんの論理からすると、
SQLよりコストをかけてしか修正できないなんてのは、
生島さんがオブジェクト指向の勉強不足であることは明らかということになってしまいますよ？

よって。

>プロとは呼べないから、プロを名乗るな！

私から生島さんに対して同じことが言えるわけです。
客観的な理由を挙げているのだからもっと言えるわけですね。

オブジェクト指向をなめないでください。
勉強不足で偉そうなことを言わないでください。
そんな人がプロを名乗るなんてのは恥ずかしい限りです。

とまあ、こういえてしまうわけです。
なぜ言えないと思いますか？
生島さんの論理だと、言えてしまうはずですよ。

念のために確認しておきますが。
私の論理でいけば、生島さんは立派な技術者だと思いますよ？
生島さんの論理では、ということです。
間違えないでくださいね？

少なくともこれまでで、
私の参加するプロジェクトにストアドプロシージャ主体のアーキテクチャを押す理由は何もないという結論しかだせません。
生島さんがメンバーに入って、作業の半分以上を行う、というのであれば別ですが。
例外はそのくらいしか思いつきませんね。

まあ少なくともここまでで技術的に根拠が上がった中ではそうです。

部下の方ともこういう話し合いをしているのですか？
それはまあ多数決に持ち込まれるでしょうねえ。

まあ、社長ならはっきり面と向かって、
お前はプロじゃない、とは言われないかと思いますが。
そう思っている人もいるのではないですかね？

生島さんのまわりの人がSQLの勉強をしない理由にもなっているのではないですか？
ある技術を勉強するべきかどうか迷っていて、よく知っている人に相談して、
この技術はこういうデメリットがあると言われていますが、そのへんはどうなのですか？
と聞いたときに。

それはお前が勉強不足なせいだ。そんなデメリットがなくなるまで勉強して初めてプロと名乗れる。
とかいう返答だったら。
SQLだろうがオブジェクト指向だろうがなんだろうが、そんな返答を聞いたらまあ勉強する気はなくなるのではないでしょうか。
それで納得するような素直な人は、技術者に向いてないんじゃないかなあ。

生島さん、お疲れ様です。

> SQLは、実際の現場で極めて広範囲に使われている技術ではないのか？
> それを常識とするわたしは間違っているのか？

もちろん間違っていません。
賛同コメントが少ないのは当たり前過ぎるからだと推察していますが、ROMっているのもなんなのでコメントしますね。生島さんにとっては今更な内容になりますが、まだ頭の柔らかい「これからの人」に向けて書きたいので御了承ください。

O/RマッパーもADO.NETも「理解していることの手間を省く道具」でしかないと思っています。何の道具を使おうが、最終的にRDBへの問い合わせはSQLに落ちているわけですから、SQLは基本であり常識です。

生成されるSQLをイメージしながら道具を使える人と、そうでない人との仕事は雲泥の差があります。SQLが解る人は生成される構文ありきで作業をしますから、複雑なSQLを作る上でも、目視で間違いが解るため生産効率も非常に高くなります。

道具が行う「SQLの隠ぺい」にベッタリ頼るのはプロではありません。基本をマスターしてから道具を活用するのがプロです。

あと、オブジェクト指向とSQLの間で混乱したことは一度もありません。両方できれば良いという単純な話ですし、少なくとも私の居るステージでは、両方できないと飯は食えません。スケーラビリティを重視してシステムの未来コストを抑えるのは重要ですが、これも両方できれば問題にすらならない。

よって、SQLが初級シスアドレベル以上に読み書きできることは”常識”です。

ちなみにPL/SQLの味を一度知ってしまうと、全部PL/SQLで実装したくなるほど甘美なものです。ロジカルな大量処理をDBMSにダイレクトに放り込める。

JDBCドライバやiBATIS、Hibernateを経由すると性能要件が満たさせない場合があります。これを突破できるカードを技術者は持つべきで、ストアドはその一つです。

両方知っているのが必須条件ですよね。
そもそもSQLが逃げる程難しいとは思えませんし、プロである限り逃げは許されません。
これからはXML/SQLとか使う時代になると思うんだけど、SQLから逃げている人はどうするのだろう・・・
ちなみに、オブジェクト指向を知らない人も多いですよね。
SQLからは逃げ、オブジェクト指向からは逃げ・・・
これがプロのお仕事なのかと疑問に思います。
逃げる人にはプロジェクトの指揮だけは取ってほしくないですね。

ストアドプロシージャが話題になっているので一言。
ストアドプロシージャはトランザクションの正規化を行うために使用するものです。
トランザクションの正規化を行わないと不必要にシステムが複雑化します。
しかし、データの整合性を記述するにはSQLは不十分でした。
そこで、PL/SQLなどは集合指向にはないif文などを追加する方向性で進化しています。
そういった方向性を無視して欲しくはないです。
データベースエンジニアリングを学んでいない人がプロジェクトの指揮をとると混乱するのは、こういった流れを理解していないからだと思います。
SQLは複雑さを軽減するために発明された言語なのです。
それから逃げる必要はありません。

文章が変なので修正します。

誤：そこで、PL/SQLなどは集合指向にはないif文などを追加する方向性で進化しています。
正：そこで、集合指向言語SQLは従来にないif文などを追加して表現力を増やす方向性で進化しています。

ちょぽりんさん、こんばんは。

レベルの低い掛け合いになってしまって申し訳ないです。

おっしゃるとおり、中身のSQLに責任を持って使う分には、O/Rマッパーも悪くはないのですよ。
「これでSQLを使う必要がない。」
と考える人がいるので困るのです。

最低限、初級シスアドの問題を何不自由なく読み書きできるレベルになれば、後は階段はそんなにありませんし、そのハードルは小さなモノですから、大手顧客が気づいて強制すれば、あっという間に業界は変わると、最近思っています。

例えば、都銀とか生保とか、メインは未だにCOBOLですが、情報系はほとんどオープンに移ってきています。

しかし、それを指揮している人たちは、本当に初級シスアドレベルでもほぼ100％無理でしょう。
その都銀とか生保とかがSQLのスキルチェックしてくれたら、
　　　　大手SIer → 中規模SIer → 零細SIer → フリーランス
って、本当に一瞬で伝搬します。
そういう流れが起きないかなってね。

上に立ってた人間があわてて覚えても、過去の検証したら言い訳できなくなるし……、そのとき大手は軒並みカスだったって評価になります。
カスだったと言えないときは、できる人は「神のレベル」に格上げになります。
そんな、激しい下克上を起きて、技術力の再見直しにつながったら、小さい会社や、フリーランサーの技術力がそれなりに正しく評価されるようになると考えています。

夢見ています。

でもそんなに、夢でもなくって、大手で実績できて実名を出して論文の1つや2つ書ければ、私にも可能だと考えています。
大手の実名が重要でね。

日経xxxxに出した論文で簡単にムーブメントが起きてきた業界ですからね（笑）。
あそこは、「大手の実名が出せる実績があればいつでもOK」らしいし……。

不況だけに、大手も経費削減のためイロイロ考えていますから、私が潰れなければ一発かまします（笑）。
（その前に潰れる可能性が高いけれど……）

しかし、若い人でも堂々と、

> 基本的に、SQLを勉強しないのは勉強不足でプロとしてどうかと思う、
> という意見さえひっこめていただければほぼ苦情はないんですけどね。

書いて来るのですから、コの業界の将来には絶望するしかないのかな……。

こんばんは。
主旨は集合指向はオブジェクト指向と親和性もあると言う事です。
オブジェクト指向だからSQLを使えないという事はあり得ません。
また、オブジェクト指向と言っても色々あり、Javaのオブジェクト指向に合わせる必要性はありません。
そもそも、システム全体の見地からDBMSを捉えられないのは、オブジェクト指向分析が出来ていないという事を意味しています。
システム全体をオブジェクトして分析した時、データベースもオブジェクトのうちの一つです。
ですから、私はシステム設計をしていてSQLで困ったことがありません。
従って、オブジェクト指向開発を理由にSQLを使わないのは間違いです。
ところで、オブジェクト指向開発をすればデータベースが使用できないのですか？
そんな事がないのであれば、普通にデータベースをSQLで操作すればいいだけの話しです。
私はSQLをシステムの複雑さが軽減できるので一つの道具として使っているだけです。
何かを否定する必要性はありません。
必要だから存在するのです。

自分は去年の春に初級シスアドを受けて落ち、今年の春にITパスポートを受けて合格したので、SQLについては全く触れていません。（笑
来年の春に基本情報を受けるつもりなので、地道にSQLについて勉強していますが…。
意外に侮ってはいけない試験ですよね、情報処理技術者試験って…。

まりもさん、こんばんは。

どういう分野をされているのか知りませんけれど、

> Joinって、型付きDataSetと相性が悪いので。

この理由ではプロとは言えるレベルにない。
申し訳ないけれど、掛け算・割り算ができない人に因数分解は説明できません。

がるです。

> もともと、RDBMSは複雑なことを簡単にできるように設計されていますから、単機能には向かない。RDBMSはオーバーヘッドが大きすぎです。
多分、ここが非常に重要なのだろうと思います。
で…Webシステムの場合。厳密には「front(ユーザ側)は単純かつ高圧」で「バックヤードはある程度複雑」な要求が多いので。
本当は「一つのdataを、front向けのデータストアインタフェースと、バックヤード用のRDBインタフェース」で扱えるともの凄く色々メリットがあるのですが(割と本気で「実装っつか設計してみようかなぁ？」とか悩む瞬間があります(苦笑))。
「単純なデータストアにプログラムで頑張って複雑にする」ことは出来ても「RDBに単機能を高速かつ軽量にやらせる」は非常に至難なので。
かくして「dataはデータストアでいいや」というのが、現状での私の、Webシステムに対する見解になる感じですね。

あとは…割といつも思うのですが。
RDBを基準に考えると、やっぱりSQLって「非常に汚い実装」に見えてしまう瞬間があるので(苦笑
割合に学習的な意味合いがこっちは強いのですが、「RDBとして真っ当な問い合わせ言語が欲しいなぁ」とか思う瞬間もまた、あります。
いや多分、本気で実装すると「実用には少々重すぎる」可能性が結構脳裏に横切りはするのですが。

以上、戯れ言失礼いたしました。

サトにゃんさん、こんばんは。

今のうちにがんばって、立派な技術者になってください。

がるさん、こんばんは。

> 「RDBに単機能を高速かつ軽量にやらせる」は非常に至難なので。

それは、RDBMSの目的外の使い方ですからね。
不要なオーバーヘッドが乗っかりますから、どうしても限界があります。
逆にO/RマッパーなどでSQLから逃げるのなら、RDBMSを使う意味もないです。

SQLは英語を目指して作った言語なので冗長ですよね。

一応、SELECT（動詞）から始まる命令文ですけれど、ネイティブで英語をやっている人にも違和感があるようですから……。最初のコンセプトで失敗していますな（笑）

生島さん、こんばんは。

今回のコメントもROMっている第3者に向けて発信します。すみません。
経験の浅い人が勘違いしないか凄く心配なので・・・
　
　
　
世界的に広く普及しているRDBの問い合わせ言語であるSQLから目を背けることは”ありえません”。これは『Dreamweaverは使いこなせるけど、テキストエディタでHTMLは書けない』と言ってる人が”技術者”を呼べないことと同義です。

「道具」にかぶれる前に基礎を知らなければ、臨機応変に活躍できるエンジニアに成り得ません。『SQLに潜在するバグは探せない』と公言してるようなものです。本質を知らない人は大成できませんし、ユーザーさんもそんな人は要らない。

SQLはRDBに対する最も身近なインターフェースであり、様々な道具も最終的にはSQL構文を生成しています。ですので、SQLの読み書きは基本中の基本、つまり”常識”だと言い切ります。

私は自社の抱えている案件情報を見ることができますが、要求スキルの項目にSQLが無い案件は皆無です。よってSQLから目を背けることは、自身の市場価値を著しく低下させるでしょう。『SQLの読み書きはできないけど、付随する道具は使いこなせるぜ！』というエンジニアをアサインできるほど大胆にはなれません。

様々な持論を展開することは大いに結構ですが、『それをお客さんに言えるか？』というフィルターを介してみるべきでしょうね。

ちょぽりんさん、こんばんは。

どうもありがとうございます。
何というか「新しいことが正しい」と考える人もいるんだなと思った次第です。

次にイロイロと書きました（笑）

今頃気付いたんですが、私のハンドルネーム間違えてますよ（笑）

>SQLは、実際の現場で極めて広範囲に使われている技術ではないのか？

ふっと思ったんですけどね。
SQLってそんなに一般化された物ですかね？
むしろ、一般化しているという幻想の上に物が言われているって事じゃないですかね？
広範囲に使われている事と、技術者が高度に知っている事は別じゃないかと思うんですね。

なので、ヘボイSQL文をチューニングする人は別途必要って事でいんじゃないですかね。まぁ、
>担当がそれぞれの専門家に分かれていたら、それぞれの良い面を活かしてそれぞれに方針を立てることができます。「専門家でない人でも作れるように」などというアマチュア指向になる愚策に至ることはないでしょう。
ってことですね(^^)

>「専門家でない人でも作れる」
この問題を理解していない↑役が沢山いるってのが一番問題ですね。
チューニング時点よりもっと早い、上流(場合によっては超上流)で参加させるべきなのにねぇ・・・

ちょっと見方を変えて、
少ない人数での開発プロジェクト：全員が高度に知っている必要性は高まる
多人数での開発プロジェクト：全員が高度に知っている必要性は必ずしも高くある必要はない
ってことじゃないですかね？
既に、今時、UIと実装も分散開発する時代に入ってますし。
実業務ロジックもフロントからは分離するとか普通ですし。

ですので、私的には、データアクセス関連は既に「特化した技術系」に属する物だという認識です。
昔の、データフロー中心のアプローチでは作れないシステムも多いですし。

また、小さなデータ量を扱う場合のSQL＋DB構造と大容量を扱う場合のSQL＋DB構造は全く異なるものですし、ゆるゆるのトラフィックかキツキツのトラフィックか等もそうですが、こういったことを理解し、且つ設計方式やプロジェクト運用、DIKS構成に至るまで広範囲に意見を出せる人（や集団、なかなかいませんが）はプロですよね。（絶対数が少ない・・・）
なので、たとえシスアドがどうであれ---(一般化された常識として云々は興味無いです)---特化したプロ集団っていうのは、存在していて然るべきだろうなと思います。
そのプロ集団が大手SIer内部要員である必要も全く無いと思います。
全ての技術者がSQLを高度に(シスアドレベルすら)知っている必要も無いと思います。
（技術者の定義をここで議論するつもりもないです。）

そのプロの１人をすら採用しないプロジェクトがあるじゃないか！
ええ、その通り・・・そこが問題です　orz

>大手の顧客（情報システム部など）が気づいたら、一瞬で大変革が起きるはず。
気づいているんじゃないかなぁ・・・
でも、安心間とか体力とか、保険とか、まぁいろいろ・・・
人の心理やしがらみってのも・・・
＠無理な要求を聞いてくれるとか・・・これは結構大きい。

ちょりぽんさん、こんにちは。

大変失礼しました。
コピペすれば良かった……。

ぱっと見、私の語感としては「ちょぽりん」の方がしっくり来て……。
「ゆうこりん」みたいな（笑）

oumiさん、こんにちは。

>>「専門家でない人でも作れる」
> この問題を理解していない↑役が沢山いるってのが一番問題ですね。
> チューニング時点よりもっと早い、上流(場合によっては超上流)で参加させる
> べきなのにねぇ・・・

まさにその通りで、開発の最終段階でチューニングとか意味が分からない。クチャクチャのテーブル構造で言語のスパゲッティ持ってこられても、できることは限界があります。

> 全ての技術者がSQLを高度に(シスアドレベルすら)知っている必要も無いと思います。

最終的には、本文にもあるとおり、私もフロントのプロと、DBのプロのコラボになるべきと考えていますから、フロントのプロはシスアドレベルすら知らなくても良い。と考えています。

ただし、担当者が切れていない現状では、必須と言わざるを得ないし、フロントとDBをまとめる立場の人（最上流）は必須ですね、注意点が分かっていたら書ける必要はないので、せめて初級シスアドレベルで。

>> 大手の顧客（情報システム部など）が気づいたら、一瞬で大変革が起きるはず。
> 気づいているんじゃないかなぁ・・・

まだ、気づいてないのでは。

私は金融系で気づいてくれないかなと思っています。
金融系は、まだ基幹はCOBOLですから情報系がRDBになってきています。
情報系なら被害は少ないけれど、もっとも保守的な金融系の動きが業界に与えるインパクトはでかい。

SQLはFROM句の順番が汚いですよね。
宣言的言語であれば、FROM Table1 SELECT Column1
になるはずであり、その方が開発ツールを作るのにも都合がいいです。
確かジムグレイ氏も不満だった様な気がします。

はじめまして。VoXと申します。

いつも楽しく拝見しております。
しかし、基本的には生島さんの意見には反発していることが多いように思います。
それでも何故楽しく拝見しているのかと申しますと、生島さんのお話は考えるきっかけを与えてくださるからです。

単純に「なるほど」と思うこともあれば、「それは違う！」と思いながらも何故そう思うのか理解しきれていない自分に気づいたり、
あるいは試行錯誤の末、自分なりに答えを出して勝手に悦に浸っていることもあります。

普段はそうして思考を咀嚼して満足しているのですが、
今回はちょっと思うところがあり、投稿させていただこうと筆を取った次第です。

私の意見の要点としては二つあります。

まずはO/Rマッパについてです。
生島さんが「O/Rマッパ＝SQLからの逃げ」ですとか、「O/Rマッパはおもちゃ」と仰ったことへの反論です。
たしかに、O/Rマッパを「SQLを書かなくていい」と声高に宣伝する方もいらっしゃいますし、
そうした邪な理由からO/Rマッパを採用する方もいらっしゃるでしょう(というより残念ながら多数)。
たしかに、現実問題としてO/Rマッパではパフォーマンス要件の満たせないシステムは多く存在するでしょう。

しかし、O/Rマッパはそれだけのために非難されるべき技術でしょうか？
パフォーマンスの問題は、小規模システムであればユーザー視点からは全く分からない程度の差しか出ないはずです。
また、ハードウェアの進化、O/Rマッパ自体の進化によって改善される可能性の高い問題です。
SQLからの逃げという観点に至っては、扱う人の問題であり、道具たるO/Rマッパの問題ではありません。
なによりO/Rマッパには、コンパイラによる高い精度でのエラーメッセージドリブン開発という使命があります。
(エラーメッセージドリブン開発自体、チュートリアルみたいな物と勘違いして歪曲した宣伝をされる方がいますね)

どんな技術も枯れて実用性を増すまでは非難の対象となってきました。
ですが、だからといって誰も使わず、ビジネス上での実績があがらなければ枯れることもなく消滅してしまいます。

生島さんはここまで見通した上で、O/Rマッパはまだ枯れていない＝ビジネスにならないという観点から、
敢えて近視眼的な発言をし、若人を煽って期待をかけているのではないか？
私にはそのように思えてなりません。

もう一つはSQLについてです。
私自身駆け出しのプログラマであり、SQLはあまり得意としていません。
(それこそ初級シスアドレベルかそれよりちょっと上くらいですね)
ですが、私的に勉強している“XQuery”という技術。
SQLみたいなものなんですが、データモデルがスラスラとイメージできて非常に理解しやすいのです。
考えてみれば、新人研修の頃Oracle公認のスクールに一週間ほど通わせてもらったのですが(内容薄いのにバカ高いです)、
ああいうところではSQLを中学生の英語みたいに文法文法で教えるんですよね。
SQLも、データモデルの概念から学べば変な先入観なくスムースに覚えられたかなぁ、と後悔しきりです。

なんだか私もあと10年したら「XQueryの分からないやつは！」なんていうかもしれませんね。
(最近KVSが人気なようで、このままXMLDBが廃れないかとｶﾞｸﾌﾞﾙしております)

長文失礼いたしました。

インドリさん、こんにちは。

そうですね。FROMからの文法になっていたら、これほど嫌われなかったと思います。
ただ、慣れたら大差ないけど。

生島さん、こんにちは。

>フロントのプロと、DBのプロのコラボ
例えるなら壁紙職人と、電気工事士の関係でしょうか。
で、コンセントがストアドだと。

今は、壁紙職人が配線しないといけないぐらい、
電気工事士がいないんですよね。

インドリさん
よーく、分かります。
ツールの入力補完機能を使うために
From句から記述するので。

まりもさん

RDBを使う以上、SQL（実行計画）の確認はお願いします。
LINQだろうが、O/Rマッパーだろうが、SQL直発行だろうが、
自身のアプリが発行する実行計画に責任を持ってください。
（でないと、ＤＢ屋が大変なので・・・）

VoXさん
RDB とXMLDB, KVSは得意分野が違うので、
どれかがなくなるということはなさそうな気がします。

以上、絶滅危惧種（？）の電気工事士でした（^ ^）

VoXさん、こんにちは。

O/Rマッパーは内部的にSQLを発行するので、中途半端な技術でしかないです。
Javaなり、なんなりで組むよりも、SQLの方が記述が少なくて済みます。
それなりのスキルの人間がきれいに書いている場合、開発工数も、保守工数も、
　　記述量 × 言語の難易度
で表されます。

「言語の難易度」が習熟によって変わってくるから、人によって意見が異なるのですが、あるレベルを少し超えたら、開発工数も、保守工数も、SQLに分があります。
パフォーマンスは言わずもがなです。

この関係は、小さなプロジェクトでも、大きなプロジェクトでも同じです。
（単機能でデータストアが目的のシステムは違うけどね）
だから、O/Rマッパーはストアドプロシージャや複雑なSQLを書いた後に使うのであればツールとして意味がありますが、それ以外の意味は全くない。

「僕たちできないもん！」は顧客には関係ないSIer側の都合でしょう。

> ああいうところではSQLを中学生の英語みたいに文法文法で教えるんですよね。
> SQLも、データモデルの概念から学べば変な先入観なくスムースに覚えられた
> かなぁ、と後悔しきりです。

おそらくそうでしょうね。
なんにせよ、RDBMSを使うならSQLができることは必須です。

エントリーポートさん、こんにちは。

> 今は、壁紙職人が配線しないといけないぐらい、
> 電気工事士がいないんですよね。

そうなんですよね。
で壁紙職人でもできるという方向にと、会社として舵を切ってしまうと、若い子達はそれが正しいと思ってしまうから、電気工事士になれる人が減ってしまう。

なれる能力があった人も、上から潰しているのが一番悪いのですけどね……。

>宣言的言語であれば、FROM Table1 SELECT Column1

>そうですね。FROMからの文法になっていたら、これほど嫌われなかったと思います。

うほっ！
なんか釣り的な臭いが・・・
つられて余計な事言わないようにしなくちゃ・・・

> わたしは初級シスアドのことを英検で言えば2級ぐらいの難易度と考えていますが、もっと遙かに高いレベルの試験だったのか？
　え？初級シスアドって、そんなに難しい試験だったのですか？！
試験勉強もせず、「どんなレベルだか見てみよう」と受けたものが、一発で通ってしまったので、とっても簡単だと思っています。
でも、私は英検2級を「難しい」と考えています。3級でさえ、通っていませんから。
まぁ、同じ理屈でいうと、受かるのに10年以上かかった2種の方が、1発で、しかも無勉強で受かった1種より難しい、って事になっちゃいますけどね。

　つまり、わかっている人にとっては「とっても簡単」かもしれないけど、
感覚的なものは人によって違う、ということです。
生島さんがいくら簡単だと思っても、そう思っていない人もいる。
「SQL が、何故難しいと思われるのか／難しい方に分類されるのか」についての考察無しに、
ただ「簡単なのに…。簡単なのに…。」と繰り返しても、
簡単だと思って欲しい人にはいっこうに伝わらない。
or 難しいと思っている人の認識は「難しい」のまま変わらない。
と、思いますが、いかがでしょうか。
特に顧客、これがコンピュータのコの字もわからないような人なら、横文字が出てきた時点で拒否しますよ。

　今の職場でも、前の職場でも、「三項演算子を使うな、難しいから」といわれます。
何が難しいのか、私にはわからない。
？と：が、文中の何処で出てくるのか、何処までが1つの式なのか。
確かにそれは、わかりにくいかもしれない。
難しいという人も、「難しいから」としかいわないから、
やはり、何が、何故、難しいのかわからない。

　わからないからわからないままで放っておくと、いつまでもわからない。これは確かに問題です。
でも、私は、これに対して、「三項演算子くらい使おうよ。」とは、言えません。
ではどうするか。新人君に使わせるだけです。
組織から出て行くであろう人より、
長くいるであろう人が使えるようにします。

　同じように考えると、「簡単なのに何故使わないんだ」と言い続けるより、
「こういうケースではこう使う。ほら簡単だ」という事例紹介を繰り返す方が、
SQL 布教に繋がるのではないでしょうか。

　私が SQL 難しいと思うのは、前から順番に読んでいけないことです。
「
「前提資格表」から「職位番号」が"02"であるデータの「資格番号」を取り出す。…（１）
「資格取得履歴表」と「社員表」から、
　「資格取得履歴表の資格番号」が（１）に存在し、
　「資格取得履歴表の社員番号」が「社員表の社員番号」と等しく、
　「社員表の職位番号」が"02"であるデータを、
　「資格取得履歴表の社員番号」でグループ化する。…（２）
「職位表」より、「職位番号」が"02"であるデータの「取得資格数」を取り出し、
　２のグループ内の数と比べ、グループ内の数が多いものを取り出す。…（３）
３の結果より、「資格取得履歴表の社員番号」と、行数（資格取得数）を取り出す。
」
昇級の前提条件の一つである資格取得数をクリアしている社員の社員番号と取得資格数を求める、のかな？
これは、順番に手続きを踏んでいくことに比べると、スマートじゃないと（今は）思います。

Jittaさん、こんばんは。

例えば、九九がない国があります。
二桁×二桁の九九？が当たり前の国もあります。

何というか、難しいか簡単かはどこかに何らかの線引きが必要です。

だから何をもって常識とするかとの問いかけです。
で、何となくできた業界の常識を常識としても良いのですけれど、明確じゃないでしょう。（分かってないわけではないけれど）
高校生から主婦から、引退した60代の方まで、最も広い範囲で取得者が多い、国家資格試験より常識に足るものが、このIT業界に他にあるでしょうか？

それ以外のものを基準におく意味は？私以上に俺様基準でしょう（笑）。

取得した後、主婦が忘れてしまっても当たり前です。
使わない分野のプロが忘れても仕方がないでしょう。

しかし、使ってないのではなく、目の前にRDBMSがあって、「O/Rマッパーを使えばよい」「忘れました」「できません」では、プロとは呼べないと言ってるわけです。

俺様基準で「俺はプロだ」と言われても、私は認めない（笑）。

それを業界の常識としては、擁護する方向にあるのは百も承知ですけれど、ユーザーが許すか試していたりしてね。

SIerが、絶対に逆らえない正論で叩けば値切れますからね～。

好況期では、叩いても大人の事情で人が集められないから、ユーザさんにもそんな無茶はできないということがあったけれど、不況期ですから、今はもっと無茶な叩き方が横行しているからね。

便乗して、正常化に協力してくれるユーザがいないかと思ってね。

下手糞ですが、煽っています。

そういう意味では、粘着君はありがたいのですけれど、あまりの無知には単純にイライラするわ～。

Ｓｏｄａさん、こんばんは。

失敬。見落としてました。

>> システム監査はまたちょっと違うけれど
……
> コンサルが監査っぽい感覚は、なんとなくわかります。

コンサルと、システム監査は仕事の範囲が全然違います。
両方やる人はいなくはないと思うけれど……。

誤読がどうの（誤字脱字がどうの）の議論はここでは何も生みませんから、他所でやっていただいた方が……。
何か生まれる議論なら歓迎です。

インドリさんが来られるなら幹事はしますよ（笑）。

私は、特に変わった人が好きなので会いたいわ～。

>まりもさん

こーアピール点がズレてるような感じじゃないですかねぇ。
生島勘富さんの主張は、

１、SQLは素人もわかるぐらいに簡単
２、素人が知っていることを、プロが知らないってのはおかしい
３、そのおかしな状況をなんとかしたい

だと思います。

まりもさんの最初の主張をみると、「SQLは難しくない」と認識しているじゃないですか。
そして、SQLを使いたくない理由が「オブジェクト指向と相性が悪い」と。
この辺から、「オブジェクト指向」を使うことへの固執が始まっているような気がします。
「オブジェクト指向」のためにSQLができたのではないと思うので、方向性が違うというか・・・
SQLでは無い、なにかを求めるほうが健全のような気がします。

「SQLを使わない」理由と生島勘富さんの主張への反論はかみ合わないんじゃないですかね？
「SQLを使わない」ことが「SQLを知らなくてもいい」という理由にはならないというか・・・
「SQLを知っているが使わない」だとしても、生島勘富さんの主張への反論にはなりませんよね？

>生島勘富さん
場所が違うけど、少しだけだから、コッチに書きますね。

>コンサルと、システム監査は仕事の範囲が全然違います。

監査って言葉を深く考えずに使ってしまいました(^^;
コンサルが監査っていのは誤解を生じますね。
こー感覚的にはわかってるんだけど、言葉で表現するのが難しい(^^;

>何か生まれる議論なら歓迎です。

そうですね、愚痴だと聞き流してください。

>インドリさんが来られるなら幹事はしますよ（笑）。

たぶん、ソレがメインでオフ会するなら行きたい人は結構いると思いますよｗ
「アレはそーいう意味だったのか！！」みたいな感動(?)がたくさん味わえそうだしｗ

ＰＳ．
英検２級というとすげーって感覚だったんだが、今はそうでもないのか(^^;;;;;;
小学校でも英語習う時代だもんなぁ。

Ｓｏｄａさん、こんばんは。

整理していただき、ありがとうございます。

次のエントリーにグチグチと長ったらしく書きましたが、要するに、どこまで行ってもオブジェクト指向とRDBは全く違うアーキテクチャーなのですから一緒にしたらダメなのです。それを一緒にしようとするのが「O/Rマッパーが」とかいう人たちです。

SQLはどこまで行ってもUIはできないのですから、他のもので作るしかないのです。私は、それぞれの得意分野を活かせばいいと。
人も…言語も…ツールも…。

インドリさん来て欲しいな～。
直接ぶつかる方が10倍楽しいと思うけど……。

こんばんは。

つまるところ、まりもさんが何屋さんかが述べられていないので、ここまでこじれているのではないでしょうか。私は業務システムの開発者なので当コラムの内容に共感できます。ですが、まりもさんが何系PGなのかは一言も述べられていませんよね。差し支えない範囲で述べて頂くことで、幾つか齟齬が解消されるのではないでしょうか。

それとは別に、生島さんがオブジェクト指向を熟知していないのでは？というカウンターアタックが発端に思うのですが。打たれたまま打ち返した、みたいな。

>まりもさん
>SQLを勉強しない人間はプロじゃない、と言い張り続けられて、

んーたぶん、データベースを扱うということに限定しての話じゃないかなと。
生島勘富さんはオブジェクト指向を否定しているわけじゃないですし。
データベースを扱うのに、もっとも普及しているのがSQLで、素人でも使っているものだと。

ざっと、調べてみましたが、「O/Rマッパー」とは表形式であるデータベースをオブジェクトの状態で扱えるようにするもののようですね。
オブジェクトには不要なSQLを意識させず、大量のオブジェクトを永続的に保存管理させるのが目的かな？
これって、データベースが表形式だから必要なんですよね？
表形式ではないデータベースが普及すればいらなくなる技術のような気がしますが(^^;

>アセンブリ言語くらい勉強せずに何が技術者かと古い人は言い張り。

今でも言う人は居ますがｗ
各種コンパイラが進化して、ヘタな人間がアセンブラで直接書くよりも効率が良いものが出力されるんじゃないかな？
「O/Rマッパー」も同じような進化をたどれるならば、支持する人が増えるんだと思います。
半端な技術だと否定されているということは、そこまで達してないと判断されているんじゃないですかね？
こーSQLに余分なものを被せて太らせたーみたいなｗ
もしくは、無理やりオブジェクト化しようとして気持ち悪いとかｗ

アセンブラ自体は簡単だけど、やりたいことを実現するには、かなり難しいですよね。
SQLはやりたいことが、それなりに実現できてしまうから素人でも使えるんじゃないですかね。

・・・で、生島勘富さんはSQLに固執してるわけじゃないんですよ。
現時点で、最適だと思うから言っているだけで・・・
もっと効率が良いものが登場したら、あっさり乗り換えるんじゃないかな？ｗ

仕様変更に柔軟に対応できるシステムが目的だった場合、オブジェクト指向ってのは手段の１つでしかない。
オブジェクト指向だから、仕様変更に強いのではなく、仕様変更に強いからオブジェクト指向を使うわけです。
十分に仕様変更に耐えられるのならば、オブジェクト指向を使わなくてもいいわけです。

手段のために、目的を忘れてはいけないのだから(^^;

ＰＳ．
あぁー過去のコラムとそのコメントを読めば、生島勘富さんの対応が厳しかった理由がわかると思いますよ。
同じことを言ってるということは、共感を得られるなにかが足りないんですかねぇ。
それとも宗教的な信仰心をお互いが感じてる・・・いや感じさせてるんですかね(^^;;;

・・・知らない間に私が洗脳されているのだろうか？ｗ

まりもさん、少し解りました。ありがとうございます。

生島さんが公開しているグリッドコントロールはダウンロードしていないのですが、要するにバインドするわけですよね。発行されるSQL構文と実行計画を自分で確認しながら製造したのではないでしょうか。しかし、まりもさんは『UIを引き合いに出されてズッコケタ』と言わんばかりの返答だったので噛み合わなかったのでしょう。

ADO.NETのご経験が4年あるそうですね。VSでExplainをキックするインターフェースありましたっけ？きちんとSQLを知っている人は、RDBを扱う開発がデータセットエディタやクエリービルダーだけでは心許無いことを知っています。正しいSQLを記述しても、デザイナが解釈できない場合もあります。それだけならまだしも、正しいSQLを壊したりもします。

さらに、手軽に使えるがために中間表のオーバーヘッドも解らず、最後に条件で絞り込んでヨシヨシとする人が多いんです。それに対して『TOYアプリだ』と言われたら、フレームワークの造りを批判する以外にどう反論できるでしょう。

私はO/Rマッパーを用いた実務経験が2年以上あり、それ自体は否定してません。解っている事の単純化ではO/Rマッパーの恩恵を受けてきました。

ですが、SQLを知っているからこそ使いこなせるものだったと思っています。

いざとなったらO/Rマッパーを採用したことに対しての責任だって持てます。混乱することなく、どうにでも直せる自信があるからです（SQLが書けることが根拠）。テーブルを何個JOINしようが、何百万レコードを扱おうが関係ありません。

あちこちに似たようなことを書いた気がしますが、ツールを使いこなすことがプロの責任ではなく、実行されるSQLが真であるかまでを確認するのが責任範疇ではないでしょうか。

RDBMSに対する最短のインターフェースはSQLであること、だからSQLは基本だとする意見に対する返答は無いようなので、宜しければ示して頂けないでしょうか。（あくまで個人的興味ですが）

> 生島さんが公開しているグリッドコントロール

読み返したら、グリッドコントロールを開示した理由が違ってましたね。
失礼しました。

皆さん、おはようございます。

何度も何度も書いているとおり、RDBを使うシステムならば、SQLは必須と書いているわけで、RDBを使わないならSQLができなくてもかまいません。

「SQLは隠蔽できて書かなくても良いから」はド素人です。

O/RマッパーはSQLをきっちり書いた上で使う分には、SQLを隠蔽するという目的とは違う使い方になりますが、全然、OKじゃないですかね。
ほぼ、全部、次のエントリーに書いています。

ただ、知ってる人は突っ込みどころはあるのですが、それはセミナーでお話しする内容なので書いていません。

生島社長、おはようございます。
えらく早起きなんですね。
それとも徹夜ですか？

>まりもさん
私はネットワーク＋組み込みエンジニアですのでSQLはまったくわかりません。
でも、O/RマッパーがSQLを自動変換するツールであるなら、SQLも知ってなければ２流エンジニアということになると思います。

私はC/C++がメインですけど、コンパイルされた後のマシン語（≒アセンブリ言語）が効率的か否かをイメージできなければ、良いソースは書けません。

同様に、O/Rマッパーによって変換されたSQLの良し悪しを見極めるためにもSQLは知っておくべきではないでしょうか。

O/RマッパーもSQLもできてこそプロを名乗れるんじゃないですか？
だから両方勉強すればいいだけだと思うのですが。

放浪者さん、こんにちは。

昔から、ジジーは早起きなモンです。

SQLと関係ない人の意見が聞けるのはありがたい。

C言語とアセンブリ言語の比較はよく出るのですけれど、C言語の方が高級言語でしょう。オブジェクト指向言語とSQLのどちらが高級言語かというとSQLの方。
その証拠に、私がここで書いているSQL文は分岐すらなく1ステップです。

つまり、O/RマッパーとSQLの関係は、C言語とアセンブリ言語の関係で言うと、アセンブリ言語でC言語のソースを吐き出すプログラムを書いているってことになる。
それをC++で書かれたオプティマイザという機能で解析して、中間ソース（実行計画）にコンパイルしてから、C++で書かれたDBエンジンが実行する。

この時点で、私の理解を超越しているのでかなり混乱してしまって……。

そうまでして避けたい技術が「顧客にメンテするのにこれぐらいできてね」って業界として言い続けてきた技術って……。

私には意味が分からない。私が馬鹿なんだろうな～。

こうやって絡んでくる人がいるということは、それぐらい業界としての常識なのですけれど、SQLが関係ない人から見てどう思います？

生島さん、お疲れ様です。

まりもさんの書きこみは私へのレスだったので謝ります。
すみません。

まりもさんも、ごめんなさい。

ちょりぽんさん、こんばんは。

とんでもないです。こちらこそ、すみませんでした。

ほんとうに疲れました（笑）
堂々と、初級シスアドレベルです。って宣言して反論されるとは思ってなかったので、本当に呆れ返って……。まぁ、お客さんは笑ってるから良いけれど。

SQLさっぱりわからんですが。

> オブジェクト指向言語とSQLのどちらが高級言語かというとSQLの方。
> その証拠に、私がここで書いているSQL文は分岐すらなく1ステップです。

これのどこが"証拠"なのかさっぱりわからんです。

επιστημηさん、おはようございます。

低級というのは、どこまでCPUが実行する形に近いか、その言語の命令文と機械語との対応が1対1に近ければ近いほど低級ということでしょう。

1ステップで実行できてしまうということは、それだけ高級なのです。

なるほど。んじゃもしSQLが

SELECT record.value FROM table WHERE record.key > 5

じゃなくて:

FROM table IF record.key > 5 THEN SELECT record.value

なんてな文法だったら低級と。

επιστημηさん、こんにちは。

多少は低級の方に動いていますけれど、マシン語に近いかどうかの判断ですから、Javaよりは遙かに高級ですよね。

皆様、こんにちは。

ずいぶん、噛み合わない議論が続きましたが、そもそも、技術者の方を直接変えるのは不可能と判断して、書いた内容です。

つまり、安くて速いものが欲しいお客様（情報システム部の方々）に向けて、初級シスアドレベルを避ける。そのレベルで設計する。結果、デスマーチという流れをどう考えられますか？

技術力をチェックして技術者を選んだ方が良いですよ。
ということを書いているのであって、今更、技術者が変わるとは思っていません。

お客様がその気になればいつでも淘汰できますよ。
何なら、手伝いますよ。
ってことを書いているのです。

組み込み業界全体の常識を語れるほどの経験がないので、
私の今いるネットワーク機器開発についていいますと、

ハード的にもソフト的にも省部品化を追及し
製品コストを下げるのが大きな命題となってますので
メモリもCPUも安くて小さなものにするために努力するのが当たり前
だというのが常識でしょうか。

ユーザは、価格と性能を他社製品と比較し購入に至りますから、
競争原理が自然と働き、作る側にチューニングの必要性を強制します。

一方SI業界の場合、
ユーザは性能に関して他社との比較ができないまま業者の選定を行わなければならず、
性能を比較されない状況では業者もチューニングの必要性を感じないでしょう。
これはもう契約書の中に目標性能を設定し未達に場合には業者に賠償させるくらいしないと
この意識は改善できないんじゃないかなー

また再燃させてしまうかもしれません。申し訳ありません。

＞一部の人が、自分が考えたこの画期的なやり方なら開発はうまくいくと力説している。
＞でも、実際に作業をしている人のほとんどが、
＞このやり方ではやりにくいと言っていろいろ問題を挙げていて、
＞そういう人のほとんどを説得できない。
→うーん。
　私は製造業で社内SEをやっているものですが、RDBを使うシステムで
　SQLやストアドを駆使する事は至極当たり前で、なぜまりもさんがそこ
　まで意固地になっているのかよくわかりません。
　私はこの業界で10年働いて、その経験からの主観ですが、多分5年や10年は
　RDBがなくなる事はないですよ。
　SQLもオブジェクト指向も両方駆使してお客様を満足させれば良いのでは？
　(ただし、生島氏が言われる通りRDBを使わない立場のSEはSQLは不要だと思います)
　両方知っているからこそプロという生島氏の主張は、筋が通っていると
　私は思いますし、同意します。
　ちなみに、うちのようなド中小企業も受注データが1日5万件以上あり、
　SQLとストアドをある程度駆使しないと全く性能が出ません。
　よってSQLのスキルは必須であり、常識だと感じています。
　(私の業界内での私自身の主観です)
どを説得できない。

放浪者さん、こんばんは。

ハードは線引きはしやすいのでうらやましいですが、ハードに近いほど競争は厳しそうですね。

初級シスアドのネットワーク系のレベルは、AクラスとCクラスのプライベートアドレスの違いが分かるかどうかぐらいのレベルです。

常識のラインをどこに引くかは難しいけれど、初級シスアドレベルのSQLができなくてもプロと言われてもね……。

まりもさん、返答ありがとうございます。

O/Rマッパーについては、生島氏はSQLを盲目的に隠蔽する事が目的なら否と
唱えています。私も同意見です。O/Rマッパーの今後の普及はどうなるか
判りませんが、少なくても我々現場に近い部門では今の技術、枯れた技術
であるSQLが重要です。
(私も生島氏が言われる通り、O/Rマッパーは怖くて使えません。
なぜなら、変なSQLを作られて実行計画を確認する事が大変になるし、
例えば請求計算が終わらなくなった場合、深夜にメールもしくは
電話が来るのは自分だからです)
他の方々が言われている通り、O/Rマッパーを勉強するなら、SQLの
勉強を事前に行なった方が効率が良いと思いますよ(老婆心ながら)。

MR.CBRさん、こんばんは。ご無沙汰です。

力不足でこんな主張をする人がいまだに絡んでくることは、なさけないです。。
はなっから力がないので許してください。

まりもさん、こんばんは。

薮蛇になるかもしれませんが、気になったので
横槍レスします。＞すいません、生島さん、MR.CBRさん

>どうしてSQLのみが特別扱いされて、全てにおいてパフォーマンス優先が許されるのでしょうか。

現状、RDBを使っているシステムで、保守中に発生するパフォーマンスの
問題って、ほとんど、DBに関するものだからじゃないですか？
アプリは安定稼働しだすと、そんなに問題は発生しないのに対して、
SQLはDBのデータが変われば、実行計画が代わり、大変なことが
起きやすいですよね。

>幸か不幸かそのへんについてはあと数年はブランクがあきそうになってきていますしねえ。
>数年後に役立つことを考えると、O/Rマッパー優先ではないですかね。
う～ん、どうでしょうか？
O/Rマッパーは流行るという気がしないのですが。

将来は、オブジェクトの永続化については

OODBが台頭してくる
RDBがObject機能を強化

というどちらかになるのではないでしょうか？
どっちにしろ、O/Rマッパーはなくなっていく気が・・・。
（ちなみに、OODBであるCacheも要望が高い為、SQLをサポートしているそうですよ。）

生島さん、はじめまして。

生島さんのコラムは、初期の頃から興味深く拝見いたしております。
皆様の熱いコメントに居ても立っても居られず、筆(キーボード?)を取りました。

私は10年程零細ソフトハウスで、特定派遣として働き、
現在は小売業営む企業の情報システム部門に所属しています。

私がコの業界に入った当初はオープン系の黎明期であり、
SAMしか知らないコボラー系SEと、業務を知らない素人PGのプロジェクトばかりで、
インデックスはおろか、プライマリキーも張っていないテーブルも普通に存在していました。
かく言う私もトランザクションの概念も知らずプログラミングしていたので
今考えると恐ろしい限りです・・・。

比較的多数派であろう事務系基幹アプリケーションを中心に、
COBOL→VB6→Perl→.NET→Javaといった開発を手掛けてきました。
その経験から言うと、生島さんの「RDBを使う以上、SQLは必須」という考えに強く賛同します。
私は別に「SQLを知らない人はプロとは呼べない」とは思いませんし、
専門分野に特化して顧客満足を得られていれば、十分にプロであると思います。
しかし、RDBを使用しているシステムの上流工程設計者がSQLを知らないというのは
あり得ないと思います。

また顧客側からすると、低コストで高品質、かつ保守性の高いアプリケーションであれば、
SQLだろうがO/Rマッパだろうが、どうでも良いのです。

恥ずかしながら、私はO/Rマッパについては詳しくありません。
もしかするとSQL以上のパフォーマンスを叩き出すモノもあるかもしれません。
しかしながら現実問題として、5年後10年後存在しているか分からない、
また技術者も少ない怪しげなモノを採用するよりは、
広く浸透しているSQLを採用するのが一般的ではないでしょうか。

ここに集まる皆様は、総じて高い問題意識を持つレベルの高い方々だと思います。
皆様がシステムを開発をするとすれば、どのようなアーキテクチャを採用したとしても
高品質のシステムが出来上がることでしょう。

ただ実際のプロジェクトにはスキルの低いメンバーも含まれるでしょうし、
スキルの高い人達だけを集めるという訳にもいきません。
そういった状況の中、データベースに詳しい人とUIに詳しい人で
適材適所で開発を行うのは、至極もっともな最適解だと思います。

最後に、誤解を招きかねない若手エンジニアに配慮する、ちょりぽんさんに敬意を表します。

今後とも生島さんのコラムを楽しみにしています。

O/Rマッパーについて、変なSQLを生成する、SQLを書かなくてすむ、というのは、ある意味正しく、また、ある意味間違った認識ではないかな、と思います。
SQLをソースコードから隠蔽するものもあれば、SQLを外部ファイル化してソースコード分離するものもあるわけです。これらは正直まったくの別物ですので、単にO/Rマッパーが、と言ってしまうと、いらぬ誤解を受けることになってしまいます。

例えばiBatisでは、XMLファイルにあらかじめSQLを定義しておき、それを呼び出す、という形を採っていますが、SQLに埋め込むパラメータとXMLとのマッピング、SQLの実行結果とgetter/setterを定義したオブジェクトとのマッピングはフレームワークが勝手にやってくれます。もちろんストアドプロシージャを実行させることも可能なO/Rマッパーですが、コードとSQLを分離する点において、非常に有用であると考えます。どちらかというとストアドプロシージャとコードの関係に近いですね。

ストアドプロシージャももちろん便利ですが、SQLの知識が少ないPGが多いのは確かだと思われるので、SQLも大して知らないのに、さらにPL/SQLやTSQLまで範囲を広げて理解しろ、というのは時間的に余裕がない場合が多いことでしょう。こういうときにコードかSQLかはっきりしないバグが出たりするのはぞっとします。
そいうわけで、ストアドプロシージャは適度に利用しつつ、基本的にはSQLで、というのが無難なのではないかと思うのですがどうでしょう。このあたりの配分は好みの問題ですかね。

個人的にはアプリケーションを作成する＝ネットワーク(通信)＋サーバ＋プログラミング言語＋SQL＋αを理解すること、だと思っているので、そのうち自分が一番注力するのはどこか、という違いはあれ、浅く広くなりとも全体を理解すべきだと考えます。
そういう意味で、自分はSQLは分からないから、と思考を停止してしまうのは技術者としては情けない気がしますね。分からないなりにも食いつくだけの努力はほしいものです。

shelaさん、おはようございます。

いろんな考え方があるのは承知していますし、SQLができない層が大量にいることも承知しています。しかし、初級シスアドという公的資格レベルで教育されている範囲でしょう？というのが主旨です。

O/Rマッパーは初級シスアドレベルにすらない人を使うという上で、是です。
しかし、是としてしまったら、会社全体でそこで成長が止まる危険性が出てきます。

RDBMSを使うPJに関わる全員が、初級シスアドレベルを超えていて当たり前。という前提になれば、O/Rマッパーなどゴミと一緒なわけです。