>オブジェクト指向言語側の人たちと担当範囲を分けて、
>お互いに専門性を持って開発ができるでしょう。

これがすんなり行くようなら何も問題はないと思うのだけど
現実的にはお願いに行くと正しく伝わらなかったり時間がかかったり。
なぜできないの？とお互いに疲弊しそう。

SQLもストアドプロシージャ（ファンクション）も苦にしない人が
育つような環境にあればいいけど、きちんと育てる余裕がないところが
大半なのではないかなぁ・・・

いや・・・SQLとかストアドがやっぱりまだツール等が充実していなくて
技術を必要としてしまうのが問題かも知れない。
狙ったデータが拾えているかどうかわかるように視覚的に
表示させるツールとか出てきたらいいと思うのだけど。。。

やのさん、こんばんは。

> いや・・・SQLとかストアドがやっぱりまだツール等が充実していなくて
> 技術を必要としてしまうのが問題かも知れない。
> 狙ったデータが拾えているかどうかわかるように視覚的に
> 表示させるツールとか出てきたらいいと思うのだけど。。。

うむ～。
技術者が技術を必要とするから問題というのは、わたしは納得しかねるな～。

初級シスアドレベルから、ステップは3段ぐらいしかないんですけどね。

あとの問題は文化として、機能単位で担当を振ってしまうことですね。
オブジェクト指向側とSQLを同じ担当者がやると、クチャクチャになってしまいますが、それを問題と思わず、「当たり前」と考える人が多いからね……。

生島さん、こんばんは。
saki1208です。

私は少なくとも4カウントくらいはされている気がしますw

それはおいといて...
SQLも"銀の弾丸"ではないと生島さんは書いてると私は読み取りましたが...
どうにも残念な感じですね。
売り言葉に買い言葉はよろしくない。
良い年して多少みっともない気が...(いや、幾つかは存じ上げませんが)
# 生島さんと私は±1歳ってとこですが...

しかし、今回の例であがっている部分まではさすがに私も読めていませんでした。
テーブルを直接参照すると粗結合できませんが、ファンクションにするとは...
余談ですが、かつて担当したプロジェクトで「DUAL」表にデータを挿入した
バカ野郎がいまして...
突然SQLの実行結果がおかしくなったことがありましたorz
注意しましょう。

粗結合って...
疎結合だろ、おいorz

生島さん、こんばんは。

行きたかったセミナーが垣間見れて、嬉しさ半分戸惑い半分で拝見しました。
（このコラムだけでお金とれそうなのに、いいのかなぁ…と思ってしまう…）

前々回のコメント欄での荒れ方で、仕事かプライベートで何かあったのかと心配したのですが、
復活された(?)ようで良かったです(笑)

現場でこれを適用する手段を考えてはみたものの、
プロジェクトが進まなくなるオチしか想像できないんですよね…
（強制的に分離するようにしか開発できないIDEのプラグインを作るとか(笑)）

既得権者が業務ロジックを易々とは手放してくれないと思うので、
分離を受け入れさせるアイデアも必要ですね。自分の閃き力の無さが恨めしい…

＞まりもさん
まだ読めてないようなので、本文から引用。
> 表示・UIに関するものはオブジェクト指向言語ですべきですね。
まりもさんはVとCの区別がついてないのかな…

saki1208さん、こんばんは。

きれいに分けれているでしょう。
ストアドプロシージャでは、オブジェクトは返せない（なくはない）けれど、プロジェクトで担当を分ける前提ができれば、ストアドプロシージャの部分をダミー（スタブ）にして簡単に変更できるようにすればオブジェクト指向側を先行して開発できます。

オブジェクト指向側はUIを担当しますし、顧客に近いのでアジャイルでガンガンやりあってくれればいい。

できあがったUIとスタブは、ストアドプロシージャを担当する者に取っては最高の要件定義書になっているのです。SQL（が関わるビジネスロジック）までアジャイルでやったら間違いなく失敗するし、ウォータフォールの問題点は皆さんご存じの通り。

変えたいのよね～。

xerenさん、こんばんは。

実際のプロジェクトでは、おっしゃるとおり既得権者とか乃木大将とか、ボスキャラがガンガン現れて出来ないのです。

サンプルを書こうが、勉強会をしようが、あまりに既得権者の利権にバッサリ切り込み過ぎるので……。

なんというか、力のなさを感じます。

お客様という神に頼るしか、私も手がない。

saki1208です。

ただ、同じ業務系でも比較的汎用的なパッケージを作成しているチームに属する
エンジニアと特定のお客様専用のシステムを開発しているエンジニアとでは意見
が分かれる気はしますね。
パッケージの場合はDBがマルチターゲット(RDBMS自体/またそのバージョン)の
場合もありますし。

私自身は弊社で進行しているどちらのプロジェクトにも参画していますので、お
互いの主張は一応理解できるつもりではあります。
# 上から下までまんべんなく作業してますので...

案件により向き/不向きはあるとは思いますが、それがどちらかの優位性を主張
するものでは無いと思います。あくまで適材適所かと...

ただ、一般的には業務システムにおいてRDBMSの変更を行うことは稀ですから
RDBMS側に業務ロジックを仕込めば後々の影響はかなり低く抑えることができ
ると思います。

>UI側に、オブジェクト指向的に記述した業務ロジックがどうしても必要だという例を挙げたのは伝わったかな。

下記ですよねえ。たぶん例が悪すぎて伝わらないんじゃないでしょうか？（素人目にも変です）

> 表示するデータがツリー形式であるような場合、ストアドプロシージャでツリー形式のデータを作ってくれるのでしょうか？

leafに相当する行数のレコードを返すくらいのSQLを書いて、表示用にたたむところだけ受けた言語でやれといわれそう。

> また、業務ロジックに深くかかわるような入力チェック、入力補完機能が必要な場合はどうなりますか？
> 入力チェックのたびにストアドプロシージャ呼び出すわけにもいかないと思うのですが。
本当に重要な入力チェックはトランザクションでやれじゃないでしょうか?
入力チェックをした後でSQLを発行したらその間に条件が変わったらどないするの？同じチェックを2箇所書くのは無駄かつ綻びのもとですよね。
入力補完機能は、候補を適当な数返すSQLをかけといわれるだけのような。

> 伝わったとすると、

反応が薄いということは伝わったのではなくてあきれられて無視されたと理解するべきでしょう。

と思ったら「まりもさん、本当に迷惑なんですけど……。」ときましたね。

まあ、もう少し書かれていることを理解してから議論したほうがよろしいのではないでしょうか。

>まりもさん
>ビジネスロジックを扱わないアジャイルって、いったいなに！？
だから、その「ビジネスロジック」をRDBMS上に作ろう!!と言う話を生島さんは
されています。

ずっと一貫してそういう話なんですが...

生島社長
今回のSQLとストアドプロシージャの説明分かりやすかったです。
私でも理解できました。
なんか頭の中がすっきりした感じで幸せな気分。

担当を分けるのはいい案ですが、どこで線引きするかが難しいとこですね。
組み込み業界でも、ハード屋さんとソフト屋さんが責任の擦り付け合いしてると
ろくなことにならないですけど、お互いが尊敬しあって協力したら楽しく仕事できますからね。

これからもDBノウハウを楽しみにしてます。

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

第３者からしてみれば不毛とも見てとれる言い争いですが、それですら『浪速の商人の掌の上だろう』と思いつつ読んでいます（笑）

ただ、多くのビジターが『当り前の常識を説いても面倒臭い事になりそう』という思いでコメントしない副作用はあるかと思います（ここに投票機能があれば良いんですけど）。

ところで、オブジェクト指向実装者とSQL実装者を分けることですら、生島さんにとっては『両方できる人が出現しない』という現実にアジャストした”妥協案”なのだと推察しています。『グダグダ言ってないで両方やりゃぁ良いじゃん』というのが何故か通じない（笑）

生島さん以外の第３者に向けて書きますが、SQLに特化することが他の技術を捨てることではないし、多くのカードを持っている技術者が、ケース・バイ・ケースでベストな手法を行使する。これは当たり前のことでプロとしての最低条件です。

エンドユーザーが求めているのは真新しい玩具ではなく、安定稼働の確たる実績でしょう。前の記事でインドリさんも述べていましたが、ACID特性を実現する上でRDBMSは一日の長（一日というか、もっと）があり、これの問い合わせ言語であるSQLを避ける理由は”何も無い”のです。

私は９年目のSEですが、これからを生き残る策として『日本企業の業務を熟知』することを命題に掲げています。業務と技術（道具）とを連結するのが我々の使命であり、これを心得ているプロジェクトは『SQLを見ただけで業務が解る』ものなのでデスマなどには成り得ません。

ビガーです。こんばんは。

>まりもさん

折角良いコラムなのにあなたの無意味なコメントで荒らされているのを見ると残念でなりません。
私自身も意図せず荒らしになってしまったということは、今までいくつかあり、ご迷惑をお掛けしていると思いますが、最低限のルールとして、自身の主張の趣旨を明示するべきです。
あなたは結局何が主張したいのかさっぱり読み取れません。相手の揚げ足というか一部の発言を見て騒ぎ立てているだけです。
そのため、第三者から見ると不毛な議論という印象が強く残ります。

いままでのコメントを拝読する限り、オブジェクト指向の勉強中のようで、とてもプロとしてのパフォーマンスを発揮できるレベルにないように感じますが、技術云々の前に、相手の主張の本質を理解しようとする謙虚な姿勢が必要であると思います。

なぜ罵倒されるのか、自分自身に今一度問いかけてみてはどうでしょうか。

> つまりその部分の業務ロジックは、ストアドプロシージャには取り込めないということですね。
> 単純にたたむだけならそんな目くじらを立てる必要はないかもしれませんが、
> 全階層が同じ種類のデータを持ち、同等に畳めなければどうなりますか？

treeがわかっていないか、ロジックがわかっていないか。
DBがわからないというだけのレベルじゃないようですね。
データ構造から勉強したほうがよろしいのではないでしょうか。

> 本当に重要かどうかはだれが判断するのですか？
> また重要じゃないロジックはUI側担当者が決めていいのですか？

重要じゃないロジックは実装しないでしょ?

普通には、UI側担当者はロジック以前の単項入力チェックまでということでしょう。任意のタイミングでの入力チェックが必要なら、入力チェック関数をSQL側につくっておいて、UIではそれを呼び出せというだけのことでしょう?

いや、まったくもってまりもさんの言葉より生島説のほうがずっとオブジェクト指向的だと思うんですが、、、

オブジェクト指向を本当に理解しているのならばSQLも必要だと考えますし、何の違和感もなくなります。
オブジェクトもデータも集合であって、そこに違いはありません。
SQLを嫌う自称オブジェクト指向派の人たちは、オブジェクト指向分析をせずに、狭い範囲のオブジェクト指向プログラミングの知識でものを言っているという気がします。
実際問題、オブジェクト指向分析の時、集合で物事をとらえれれば何の違和感もなく、SQLを使用して保守性が低下するとは思えません。
そもそも元をただせば、SQLは複雑性を下げるために生み出された技術ですので、それを避ける事の意味がわかりません。
オブジェクトもデータも集合なんですから、SQLを嫌う人が言い訳の材料としてオブジェクト指向という単語を持ち出しているのだと思います。
いわゆる似非オブジェクト指向派です。
偽物ですので、生島さんは気にせずガンガンやっちゃってください。
※でも言葉遣いには気をつけて。
ともかく、プロなんだから両方勉強すればいいと思います。
ここを見ている学生や新人さんは気にせず両方学習して下さい。
ちなみに、SQLの守備範囲は当然データベース関する部分です。
データベースエンジニアリングを学習すればおのずと分かります。
棲み分けははっきりしています。

まりもさんの主張は端から見ているとどうにも噛みあっていないようには見えるのですが１点だけ気になったというか。

>業務ロジックの変化により、「重要じゃない」入力チェックの内容が変化することは十分に考えられますが。

生島さんのやり方を推進すると、業務ロジック（根幹となるロジック）側とＵＩ側（入力チェック／表示用データ加工とかそういうロジックは含む）で担当が分かれてきます。

SQLとJava,.NETなど現実的には双方かなりのスキルを有している方々は少ないので会社すら別になる可能性が大ですよね。

このような場合の弊害としては、不要なロジックを業務ロジック側に実装してしまうことが多くなってしまうこともありませんかね？

例えば、データ的にはありえるけど入力チェックやＵＩ側の加工でロジック的にはありえないケースも業務ロジック側で考慮した形を作ってします。

こんな例はとりわけたいしたことないですが、他方の変更に対するもう片方の変更に対しては保守性が下がるのかなーっと。

まぁ上記の話は技術的な話（議論の中心的な話題）とはまた別なので、道がそれていますが。。

盛り上がりそうなネタキター！なので楽しみですが。
（意味無く発散する期待大）

それはおいといて、

ちょっと今回の記事は難しいと思いました。

まず、出だしの「保守性」
>オブジェクト指向言語 ＞ SQL ＞＞ 混在型
>が成り立つと、わたしは考えています。

これ自体、広い範囲を抽象的な言葉(単語)でまとめてしまっています。
例えば「オブジェクト指向言語」という言葉の中には、当然データを扱うアーキテクチャや、データの永続化、一時的なデータのアクセス等についての某かの経験と知識が必要なのですが、それ自体が深淵だったりしますよね。
SQLしかり。
（まぁ、主観的になってしまうって記事冒頭でも言っていますが）

なので、ここは固定的に「何についての保守性だ」と決め打ちせずに、
・コードの保守
・データアクセスに直接かかわるコードの保守
・データの保守
・構成の管理
・その他

などを混然一体となったものとして捉える必要があると思いますが、なかなか、そうは読み取れない人も多いでしょう。
SQLひとつとっても、「SQLステートメントそのもの」「生SQLを発行するという実態(コード)」「コンポーネントが暗黙に発行するSQL」「Viewなども含めたDBのオブジェクト」などなどありますからねー。
単純に、SQLを発行するクラス vs ストプロ　としてしまうと、これは異種団体格闘技戦になっちゃいますし・・
（立ってるボクサーと寝てるプロレスラー）

また
>オブジェクト指向言語 ＞ SQL ＞＞ 混在型
これが成り立つモデルについては、特に言及していないので、そこは想像しながら導入の部分からしばらく、読み飛ばす必要があります。
これが、かなり難しい・・・罠？
ってうか、「何の保守性」とはっきり言ってない時点で罠の臭いがあります・・

>いずれにしても、SQLがちゃんとできない人がどうやって、「SQLで処理するのは良くない」と結論を出しているのか
ここらあたりまで読み飛ばさないと・・・

ここからは記事への意見ではないですが、

業務プロセスをシステム化するスタンスの時には、オブジェクト指向との親和性は低い。
業務の関係性をシステム化するスタンスの時には、オブジェクト指向との親和性は高い。
のはず。（言語の話ではない、特別なテクニックの話でもない）
顧客もデベロッパーも同じ土俵でって事が前提です。
（まぁ下は、業務に存在するプレイヤーや扱う物の関係性ですから、OOその物ってことですが・・・）

生島モデルでは、だいたい、中小企業でSQLもそんなに知らない技術者や責任者が多く、ニッチな技術は必要の無いケースとなっていますから、「業務プロセスをシステム化するスタンス」が多いと思われる。
この場合、当然「オブジェクト指向との親和性は低い」のである。つまり、SQLが悪いとか云々は関係ないのであーる。
（どちらかというと、OO言語よりCOBOLで作れよ！なのである。）

そして、OOでのデータアクセス全般と、プロセスフロー型（手続き型でも良し）でのデータアクセス全般では、固有名刺は共通しますが、実際のアクセス粒度やトランザクションの範囲、データの分割(インデクスも物理も色々)単位など、様々な部分で違いがある事は、皆さんご存じのはず。なので、そういった事を踏まえて、くれぐれも「地雷に引っかからない」ように読むと良いと思います。
いや、本質を読み取ろうって事です・・・

本質は何？
SQLもストプロもまともに使おうよ。ってことと
セミナーの方もよろしく！ってことでしょぅ？

仮定に色々突っ込みたくなるけど(まぁあそれが面白いのですけど)、テキスト型コミュニケーションの限界がありますから・・

ずれてるかな・・・？

皆さん、こんにちは。

異物が入ると、コメントすらしにくいので、やっぱり、考え方が違うのですから、きっぱりと分けるべきです。

まとめて感想を。

もう、何年も前から同じことをやっていて、自分で面倒見れる大きさのプロジェクトを超えると、必ず異物が入って制御不能になります。
まぁ、どっちかというと私が異物なんですけどね。

マネージャ（コードは知らん）、リーダ（現役バリバリ）、レベルでSQLは初級シスアド以下という人は一杯いて本当に変えれないのです。
私は押し付けているつもりはないし、平易な言葉で説得しているつもりですけれど、相手が理解できるレベルにもないことが多いのでどうしようもない。
初級シスアドの解説から優しく始めても、相手もひとかどの技術者ですから、「馬鹿にされた感」が出て聞きゃしない。

社内コーディング規約から、社内文化までぶった斬らねば前へ行けませんので、大抵負けるし、分かりましたといいながら、やっぱり機能単位で担当振ってるし……。
彼らが理解して、担当を切り分ける能力を付ければ、「銀の玉」とは行かずとも、いろんなプロジェクトで改善は見られると思います。

ただ、現状では理想論でしかない。理想論を言ってるうちはロマンチストのアマちゃんでね。

マネージャ、リーダクラスを説得するのは無理だから、顧客が気づくまでは「絵に描いた餅」ではあるのです。マネージャ、リーダクラスに理解があれば、メンバーの教育から始めてもおつりが来るのですが、マネージャクラスが足引っ張るとどうしようもない。

プロセスア中心アプローチ（POA）か、データ中心アプローチ（DOA）か、オブジェクト指向（OOA）かについては……。

顧客はほぼPOAで来ますから、顧客と話するときはPOAが適していると思います。システムのグランドデザインを考えるときは、POAからDBの部分をブラックボックスとしたOOAへ変換して考えています。DBの部分はどうしてもDOAになりますね。

私は、上に立つなら全部必要だと思うのです。
反対する人は、私より、特定の技術（OOA）に固執しているように思うのですけれど、一般的には私が異常者なのね……。

　　　　オブジェクト指向言語 ＞ SQL ＞＞ 混在型

の中には、多分に主観と暗黙の前提が含まれているて、その前提を全部書くなんて、個別の事情を書けないこのような場所では不可能なことです。

正直、宗教論争はしたくないのですけれど、考え方としてはDBを変更したいパッケージ以外（私な2回しか経験ない）では、小さなプロジェクトでも、大きなプロジェクトでも、ほぼ使えます。

でも、理解して貰うには、
　　（最低）初級シスアドを超えるぐらいのSQLのスキル
　　＋ 他の言語のスキル
　　＋ 業務理解
　　＋ 各種プロジェクト運営の経験
がないと多分無理。

SQLのスキルが足りないと反発しか出ないのは仕方がない。
それを棚上げにした議論には価値がない。
これを超えさせるには顧客を巻き込むしかないかと、「初給シスアド以下じゃないか！」で気づく人は気づくと思ったのですが、甘かったな～。

それにしても、ずいぶんとレベルの高い読者が付いたモノだと、何人か集まったら、どんなシステムでも作れそうですね（笑）

感謝感謝です。

ちなみに、サンプルは最初書いてなかったのですが、前半だけだと本当に宗教的な匂いしかしないので、後付けでサンプルも書いてみました。
ちょっととってつけた感が……。

まりもさん、こんにちは。
また、横槍ですが、

>>最低限のルールとして、自身の主張の趣旨を明示するべきです。

>何度か明記したつもりではいるのですが。

>オブジェクト指向設計で業務ロジックを組む勉強もすべき。

>です。
う～ん、最初に受けた印象では、

ORマッパーを勉強しておけば、SQLは不要

と仰られている感じでした。

で、RDBを使っているのにSQLが要らないだと～
と生島さんとの水掛け論に発展
そのあとは、刺が強く感じられて、
趣旨が分からない感じでしたよ。

で、本題の
オブジェクト指向設計で業務ロジックを組む勉強もすべき。
ですが、今、SQLが除け者になっている以上、
みんなやってるんじゃないのですか？
（まさか、こっちもやっていないとか・・・？）

>ORマッパーを勉強しておけば、SQLは不要と仰られている感じでした。

同感です。それで私もオブジェクト指向分析ではデータも含むと書きました。
オブジェクト指向って言っても、色々あり集合で纏めて考えます。
特に分析段階では、SQLとかC#とかJavaとかF#とか言語を想定しません。
システム集合の中にどのような要素が含まれるのかを概念的に分析します。
これが重要で、もしSQLを忌避するのであれば分析と設計に狂いが生じます。
例えば、商品という概念はテーブルかオブジェクトかなんてどっちでもいい。
そのシステムに於いて、商品という概念がどういうものなのかを分析しなくてはなりません。
そうして、情報処理システムの世界へ落とし込むために設計するわけです。
あくまでも商品という概念は現実の一部をコンピューターシステムで表現したものにすぎません。
その表現法の時にデータベースをもっとも旨く扱えるSQLを忌避されると、余分な情報（プロセスやデータ）が付加された歪なシステムが設計される事になります。
すなわち、現実の一部がさらに失われる事になるのです。
こうして、お客様が考える概念と乖離したシステムが出来上がる結果になります。
オブジェクト指向はデータも含む概念である事と、オブジェクト指向が現実の一部でしかない事を念頭に置かねばなりません。
もし上流がSQLから逃げるのであれば、一層の事初めからDBを使わない方がよろしいと思います。
DBを使いながらそれを得意とするSQLを避けると、避けた分だけシステム設計が複雑化し、分析に狂いが生じるのです。
SQLから逃げた分は下流にデスマーチとなって現れ、お客様にとっては見知らぬシステムとなって現れます。
趣味ならば大いに結構ですが、商売である以上お客様の望むものを作らねばなりません。
逃げは許されません。

生島さん、こんにちは。

神頼みしようにも、神様同士の横の連携が薄いので、
仮に切り込めても単発式になってしまうのが問題です。

既得権者に近い立場で本コラムに感化された人が切込み隊長になってくれるのを祈りつつ、
どこかが前例を作ってくれたらそれが上手く伝播する方法を考えた方が良いのかな…
(日経コンピュータ寄稿案が良いですけど、これだと生島さんの名前が載らないのが難点…)

本当はレス控えようかと思ったのですが、細かい援護射撃だけさせてください。

＞ ちょりぽんさん
少し諌められてしまいましたが、面倒な以前にココが学校ではないというだけです。
みなさん律儀にヒント出してますよ。全然拾ってくれないですけど…

＞（株）ポチさん
UIでの精査は回線を介さないメリットがあるだけの利便性機能です。
proxyを噛ませる等でいくらでもデータ改竄はできるので、
データの整合性を保つのはあくまでサーバサイドです。

＞ oumiさん
ちょっとずれて、もとい引っ掻き回しちゃってますよ。
意味が分からない人には逆の意味に取られそう。(本質でない罠に注視してしまう)
意味無く発散しないように要素抽出するのではツマンナイでしょうか？
（言うまでも無く、適用範囲は個人の判断で です。）

＞ まりもさん
>私が攻撃していたからですね。
いえ、全然違います。むしろ当を得た攻撃なら大歓迎です。
「かけ算割り算ができない人間に因数分解の説明はできません。」
何ができないから周りがこのような反応をするのか？
ヒントどころか答えが過去のコメントに書いてありますよ。

xerenさん

援護射撃で私が撃たれる理由が判りません（笑）

まりもさんに反論すると、収集が付かないと感じてる人が多いと予想して書いたんですが。

あと「四人纏めてバッサリ斬ってやったぜ」みたいなコメントは控えたほうが良いでしょう。それは生島さんがやるべきことですから。

少なくとも私は「諌められてしまいましたが、」の一句にピクリと来てます（笑）

＞xerenさん

ちなみに、まりもさんは理解して議論していたので問題ないのですが
ここでいうＵＩを誰もクライアント（ブラウザ）とは考えていないですよ。

サーバサイド内での観点切り分け前提での話です。

コメントまで見たのは久しぶりですが
最近のエントリーはなかなか白熱？した感じですね。

とりあえず、皆さん『品質の高い』iアプリ（Java）を作ろう。
メガアプリなどの大容量ではない、50xiシリーズ（90xか？）並の。
成果物は、DBと接続すれば何でもいいはずです。
ゲームでも問題ない・・・あ、ちょっとあるかもしれません。
まぁ、成果物は「ほぼ」何でもいいはずです。
議論はそれからです。
・・・議論がなくなるかもしれません。
ロジックがどちらにあるべきかを考える隙すら与えてくれません。
（・・・正規化失敗すると隙ありますが・・・）
単なる入力チェック、入力項目間のチェック、マスタとのチェック
入力データの加工、登録。
まぁ挙げるときりが無いので大雑把に。
それぞれがクライアント、サーバーのどこにあるべきか、おのずと
整理されていくと思うのですが。
ちなみに、どこからが業務ロジックにあたるのか。
大雑把に言ってしまえば全部そのシステムのロジックなので
業務ロジックですが、UIとBPに分けて考えれば簡単に答えが
出てきます。

>ORマッパーうんぬんかんぬん
SI ObjectBrowserがあればテーブル変更できるけどAlter文は
発行できませんとか、プロシージャの呼び出しもGUIがないと
・・・など言い放った入社１ヶ月当時のいや、SQLデビュー
１週間だった「あ～り～」というアホと同じで、ツールなどは
便利ですが根本的な部分が分かっていないと結局外部への責任を
持てないと思うのですが。
その辺が分かっていて選択した方へは批判すべきではないですね。
それ以外の方へは批判より、諭しましょう。
今回がどっちか？・・・発言は控えます。

追伸：
>, 商品名
>, fn_標準価格（得意先CD, 商品CD） AS 標準価格
>, 売価
最近、これは嫌いだ。
Batch系でこれをやると遅い。。。
正規化失敗か？ファンクションは一瞬なのに。
SQLもマスタからデータ取得するだけのただ件数が多いだけで
解析はすぐなのに・・・
これをやるだけで遅くなる・・・Batchでは一時テーブル化です・・・
（全部が全部じゃないですがね）

生島さんは開発者のレベルの低さを憂いて、その目線から見てて
まりもさんは開発者としてSQLやオブジェクト指向は使えて当たり前。
その上でどうシステムを組むのが理想的か？という視点から見てる気がします。

元の視点が違うので、食い違いが出てるのでは？

自分もSQLチューニングと化しますし100行を超えるSQLやストアドも書きますけど、
全然SQL使ってる気はないです。完全にオブジェクト指向の人間です。java屋です。
fn_標準価格とかはSQLを使ってるうちに入らないです。あたりまえです。
まりもさんもそういう話なんだと思います。

言い方は悪いですが、VB6で書てきたシステムのレベルのSQLの話と
会計システムの複雑に承認や商品、タイプなどが絡んだ条件の計算データを出す
システムの話の違いでは。
もちろん全てストアドで書くことは出来るかもしれませんが、
あ～り～の例のように使い方しだいで問題が出るのは変わらないですし。

結論的には私は見ていて、生島さんもまりもさん両方の意見がその通りだと感じました。
ただ、見ている視点が違うだけで。

自分の文を読み返したら、白熱した議論に当てられたのか
ちょっと言葉尻がきつくなってますね。。

誰かを攻めようとか、他意はないです。申し訳ない。

>初級シスアドレベルから、ステップは3段ぐらいしかないんですけどね。

このレベルにいない人を排除するのか使っていくのかの
どちらかなんですよね。排除もできず教育もできずじゃ困った困った。

>あとの問題は文化として、機能単位で担当を振ってしまうことですね。

担当を振って責任を負わせるのはどうかと思います。
チーム開発力が大事だとリーダーが常に言って聞かせる必要を感じます。
チームにSQLに強い人がいたらその人に頼ればいいんですよね。
（展開できればなお良しですが）
メンバーの個々の能力をそれぞれお互いが認識できていれば
開発はうまくいくと思います。

※でもやっぱり全部の技術に精通している人がいたらそれが一番助かるなぁ・・

生島さん、こんばんは。
また、本筋と違う話ですいません。

>SI ObjectBrowserがあればテーブル変更できるけどAlter文は
>発行できませんとか、プロシージャの呼び出しもGUIがないと
>・・・
そういえば、昔、下についた新人に、
GUI禁止（Object Browser, ffftp等）
すべて、vi, sql*plus を言い渡した記憶が・・・
めんどくさいおっさんと思われてたのかなあ。

でも今でも言うかも。

画面を全然更新しなかった挙句、言葉の選定がマズすぎました。
不快に思われた方々、失礼しました。

援護射撃は単純なレス付けという意味で対峙する意図はなかった…
だいぶ伸びてるので生島さんがレス付けを飛ばすであろうところに反応しただけです。
(生島さんのバッサリを期待する肝の部分には触れてないと思います。)

＞ちょりぽんさん
副作用のくだりはそう読めるのですが、
結果的に意図されたことと真逆の反応をしてしまったのは申し訳ない。

＞（株）ポチさん
最後の方を読み飛ばしてました。論点ずれてましたね…

慣れないことをすると粗だらけだ…

>まあこんな記事もあるので。
>http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel
>割と普通なのかもしれません。
あれ？これを読んでもこの議論につながらないのは私の毒か威力がないのでしょう。

とその記事を読んでいたらアクセスランキング欄に
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL
う～ん、宗教論争をここでしている気がしてきました。

という感想ですが・・・違ってたら申し訳ないです。

連投すみません。

>毒か威力
読解力です。
毒・・・もう駄目ですね。

仕事に・・・SQLパフォチューに戻ります。

皆様、こんばんは。
saki1208です。

少し冷静になってきた空気が漂ってますね。良い傾向ではないでしょうかw

できる人がいればその人に頼るってのは少し危険な香りがしますね。
得てしてそういう人は周りの人が持っているほとんどの分野で「デキる」
評価になってないですかね?

全員が何かしら得意分野があり、お互いに補完できれば良いですがそういう
環境はごく稀な気がします。大抵はなんでもできる人数名と何もできない烏
合の衆の場合が多いかな。経験上...

最終的にデキる人にすべてが集中し、モチベーションを失ってデキない人化
していくことも多いですよねorz

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

直近のコメントを拝見しておりますと、いささか違和感を覚えます。

一連のやり取りは、前々回の記事、
http://el.jibun.atmarkit.co.jp/g1sys/2009/11/post-04a4.html
からで、まりもさんは最初に

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

と仰っています。その後、

> ブラックボックスになってしまうのもいやなので、別の人間に任せるというのはあまり解決にならないでしょう。
> だから、せめてO/Rマッピングで隠ぺいしようとか、そういう方向に向かいたくなるのです。

と展開されてますね。そして『SQLを避けるのは初級シスアドレベル以下だと公言しているようなもので、プロとは言い難い』という意見が、生島さんを筆頭に幾つか寄せられた中でも、独自の理論でもって頑なに反論なさってきたと私は見ています。

直近のコメントに対する感想を正直に申し上げれば、
『あれっ、なんか柔軟になってる？』
です。

どこかで意識改革があったのでしょうか？もしそうであれば大変結構なことだと思うんですが、皆さんの意見に感化されて変化した描写が、これまでのコメントに見つかりません。

もし、SQLを学ぶことを視野に入れたのであれば、考え方が変わったことをきちんと名言するべきだと思います。

でなければ、前々回からのやりとりは一体何だったの？ということに成りかねません。

何やら平和ムードになってますが、一番納得できないのは生島さんでしょう（笑）ケジメが必要だと考える私はジジイでしょうか。

saki1208です。

>まりもさん
>>最終的にデキる人にすべてが集中し、モチベーションを失ってデキない人化
>>していくことも多いですよねorz
>もうちょっと計画的に仕事を配分すべきなのではないですかねえ。
毎回こういう形で一文だけ読んだようなコメントを残すから、喧嘩を売っている
と取られるんじゃないですか?

仕事を振りたくても危なくて振れない人/振って貰えない人がいるから最終的に
そうなると書いてるのに...

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

> この状況で。
> オブジェクト指向の専門家を個人的に目指すのは、間違ってますか？

私としては、狭い世界の身近な同僚は比較の対象ではないんですよね。凄いと思える人が居たなら別ですが、現状そういった人脈は100％他社エンジニアとの人脈に依存してます。うちの会社、30人も居ませんから（笑）

同僚のスキルに縛られず、グローバルな視点で今後のキャリアを考えていけば自動的に答えは見いだせると思っています。

まりもさん、追記です。

> SQLをちゃんと勉強するかどうかも迷ってきてはいますが。

迷っていらっしゃるくらいなら、もう豪快にやっちゃいましょうよ。
現状におけるO/Rマッパーの至らない点が見えるかもしれませんよ（笑）
（見えてこそプロフェッショナル！）

もちろんオブジェクト指向側だけでなく、RDBMSとの対話の面で色々な物が見えてくる。

私はRDB大好きなんですけどね（笑）仕組みを知れば知るほど、これ（RDB）造った人は天才だと思えます。奥が深いです。

相当酔ってますね。すんません。
この季節柄、大目に見て頂ければと思います。。。

まぁ、仕事を振れないような人がいること自体が間違っているのですけどね。

見てる相手が同僚だというスケール感に意見したつもりだったんですけど・・・

それじゃ尚の事、社名と実名を出してまで、改革を遂行しようとしている生島さんとは話が噛み合うはずがないのかな、と思いました。

いろいろ言いたい事が残っている（と言うより、後から後から湧いてきてもぅキリがない）のですが、生島さんのコラムなので自粛。

もう、ねんねします（笑）

>まりもさん

基本的には私は仕事を「振られる」側の立場ですから...
自分が仕事を振る立場としては書いてないです。
もちろん振られる立場としては自分自身の作業量のリミット直前でノーと言
いますけどね。

>いろいろできることはあるでしょう。
>振れる仕事を探す
　私自身がリーダーを務めるプロジェクトでは実際にそうしますよ。
　でも、そんなに雑用ばっかり発生しません。

　プライドではプロジェクトを成功に導くことはできませんが、そういう人
　たちほどより上層にいたり、変にプライドが高かったりしてレベルの低い
　仕事を振るのも相当に苦労しますね。

>教育して能力をつけてもらう
　教育するのもコストがかかることはご存知ですよね。
　プロジェクト内で教育では終わるまでにものにならないでしょう。

　本来は飯の種ですから、自分で進んで勉強するべきです。
　というか、しない人に未来はありません。
　(これが分かってない人が多いから困るんですけどね。)
　(コストをかけてまで教育して身になるレベルの人は実は既に自分でやって
　いることが多いw)

>首にする
　少し乱暴すぎるでしょう。
　(これが簡単にできればコストは抑えられるでしょうね。税金が減るみたい
　なもんですw)
　また、管理職ではない一般社員にそんな権限ないでしょう。ましてや一介
　の特定派遣で働くエンジニアとしてはそんなこと...

>最初から入れない
　これも鶴の一声で使わざるを得ないことが多いですね。
　使えないと分かった時点で排除するよう働きかけることはもちろんできま
　すが、今までもこれからも同じ職場で毎日顔を合わせる人間ばかりですか
　らそれも難しいですね。

参画しているプロジェクトのことを本当に考えているのであれば、1 や4 は
雑作も無いことです。人間関係的にはヒビが入りそうですが...
しかし、1 はまだしも4 は何の解決にもなりません。別のプロジェクトで同
様の状態になるだけです。ここらへんは、「課」とか「部」とかのレベルで
考える話でしょうね。

>一部の人ばかりに仕事が集中しない管理もいろいろ方法はある。
>まあ私にやれって言われてもできないかもしれませんが、どんな有能な人でも無理って>わけではないので。
>決定事項のように言うのは違和感があります。
上に書いたように「振る」側の立場としては書いてませんし...
あまり一般的ではなかったかもしれません。
しかし、方法はあっても常に実行可能な方法ばかりではないでしょう。

生島 さん、こんばんは。

>日経コンピュータへの寄稿は何度かチャレンジはしています。

日経コンピュータって、技術的には微妙な記事が多いですよね。でも、エンドユーザ（情報システム部門）への影響はかなりあるという．．．

ずいぶん前に読んだ記事でしたが。オブジェクト指向では、「全てをオブジェクト」とするのが「正しい」から、項目を全部オブジェクトにして、リモート・メソッドとして呼び出しました。そうしたら、遅くて使い物になりませんでした。というのが、「失敗例」として紹介されてました。

いや、やる前にわからんか？ という．．．

>SQLではIF文も書けないわけで、「全部DBサーバで」というのは、あるスキルに到達しないとかなり恐怖を覚えます。例えば、セミナーの嫌らしい問題が、30分でも1時間でもいいから、「やったら出来るよね～」ってレベルになれば、その恐怖感もなくなる。

SQL って、再帰なしの Prolog なんですよね。

Prolog という言語は、ヨーロッパではある程度人気があるみたいで、例えば、Erlang は思いっきり影響受けてますね。関数型プログラミング言語が流行れば、SQL に対する嫌悪感も減るかもしれませんね。

まあ、Prolog は論理型プログラミング言語というジャンルで、またかなり独特なんですけど。

参考：

「PrologとSQLの関係」
http://www.thinkit.co.jp/article/157/3/3.html

まりもさん
うーん。先ずはオブジェクト指向分析、オブジェクト指向設計、オブジェクト指向プログラミングの三つを覚えたほうがいいと思います。
貴方の言うオブジェクト指向は、多分Javaのオブジェクト指向プログラミングという狭い範囲のものです。
もっとオブジェクト指向とデータベースエンジニアリングを学習したらSQLの重要さが分かると思います。
それに、オブジェクト指向言語を一つ覚えただけで、オブジェクト指向プログラミングを学んだ事になりません。
関数型言語のオブジェクト指向や、Smalltalk流のオブジェクト指向にも触れたらそんな事言わなくなりますよ。
オブジェクト指向分析、オブジェクト指向設計、オブジェクト指向プログラミングは三つセットで覚えましょう。
さらに、DOAとPOAはオブジェクト指向を考える上で役立ちますから覚えましょう。
それでこそオブジェクト指向派を名乗れます。
ちなみにPrologはSQLと同じ第5世代言語です。
Prologは知識データベースにも使われたりしますので似ています。
さらには、オブジェクト指向Prologなんてものもあります。
オブジェクト指向って、何のパラダイム言語にも付加できるのです。
前にも言ったようにSQLにもオブジェクト指向要素が付加されていますので、オブジェクト指向だから・・・は言い訳になりません。
何でも学習しましょう。
好き嫌いは通用しません。

技術的におかしいとみんなが言っているんだと思いますが・・・
オブジェクト指向言語で処理したら保守性が悪い！
という言い訳は、技術的に成り立ちません。
もっと簡単に言うと、オブジェクト指向の一部であるデータを軽視してオブジェクト指向を語るのはおかしいという事です。
オブジェクト指向は、プロセス中心とデータの中心の見かたをプラスする形で発展したものであって、それら前の段階を無視していいわけではありません。
兎に角、この手の言い訳をする人は、オブジェクト指向を理解していない事は確実です。

おはようございます。

>オブジェクト指向分析、オブジェクト指向設計・・・

みなさんは、どういう良書を読まれているでしょうか？
スレを呼んでもう一度基本に戻ろうと思いましたので、何か
お勧めがあればお教えください。

お疲れ様です。
結局SQLを勉強しないと、RDB側でどこまで出来るかわからないんですよね。
参考書を訳も分からず片っ端から数十冊用意するより、わかっている人に数冊選んでもらったほうが効率が良い。
で、
RDBでも必要そうなテーブルに片っ端からアクセスして手元でうにゃうにゃするよりは、ストアドプロシージャ等を使って
クライアント「こんなデータ頂戴！」
サーバ　　　「あいよ！」
ってな方が効率が良い。
O/Rマッパー等のクライアント側でやるより、RDB側でブラックボックス化した方が効率が良いですよ、と。
そのためにはSQLの勉強が必須ですよ、と。

オブジェクトオブジェクト言いながら仕事をRDBでなくプログラム側に集中させるのはなぜですか？ってのもありますが。

オブジェクト思考（とまとめてみる）はいまだに勉強中だったりしますが。
基本的にパターンばかりで、現場の作業とマッチングさせるのが大変です。
経験を積まないと、どのパターンを採用するかの判断がつかないです。

大阪…行ってみたいなあ。
現在の仕事の納期があるので今回は厳しいですが。

>まりもさん

素朴な疑問があるのですが
RDBを今まではあまり意識してこなかったとのことですが
RDBを全く使わないシステムばかりをやってきたわけじゃないですよね？

O/Rマッパの話があったことからも、RDBは向こうにはいるけど、意識を
しないようにO/Rマッパ使ってやってきてたということですかね？

その場合、O/Rマッパが吐き出すSQLや、DB側での実行計画などはどうさ
れていたのでしょう？

また、DBは単純な永続目的だけで業務ロジックを果たすテーブル間の結合
であったり、色々なロジック（SQLでごりごり書くと長くなりそうな部分）
はO/Rマッパで実現できているのでしょうか？

最近O/Rマッパ触ってないので純粋な好奇心です。
（勉強不足ですいません）

----

少し話しはそれて、
やはり生島さんなども言われていますが、テーブル、カラムをJavaなど
にO/Rマッパで結び付けようとすると結構な数のクラスや属性が出てき
ますよね。

めんどくさいし、なんか無理やりこういう状況にしないと使えないって
いうのもイヤだなーと前から思ってはいました。

上記の解決策が「EclipseなどIDEや、そのプラグイン、はたまた設定や
アノテーションで簡単に自動生成できるから工数かからないよ！」になっ
ているんですが、そもそも論としてどうなんだろうな？と。

そんなこと考えるなら素直にDBでやれることはDBでやって、Java側との
結合部を簡素にした方が全然いいなと思っているところです。

過去の発言に囚われると混乱して揚げ足取りになりかねませんし、、、

>まりもさん
改めて説明しませんか？
SQLで実施せず、オブジェクト指向言語側で実施する利点を。
それからだと思います。
○○でxxだから△△なんだよ。な、いいだろ？と。
□□で※※なんて++とかどうすんの？ではなくて。
相手が自分の理論の説明しかしないと思っていても（思ってない？）
相手の意見への反論とかではなく、自分の意見の説明を。

あ、私？
基本、SQL派。細かい部分に違いはあるかもしれませんが、
相手の経験値の高さと個人的な考え等ありますからその辺の誤差の範囲と思っています。

----
余談：
炎上大好きだけど・・・
・・・とりあえず、コメント長くて読み直しても最初のほう忘れちゃう。。。

こんにちわ。

>ちょりぽんさん
>私はRDB大好きなんですけどね（笑）仕組みを知れば知るほど、これ（RDB）
>造った人は天才だと思えます。奥が深いです。

これ分かりますわ。
DBってものすごく奥深いものだと常々思います。著名な方に勉強方法や書籍を
紹介していただき勉強していますが、SQLのすごさに改めて目からうろこが
落ちることが多いです。

>まりもさん
>オブジェクト指向の専門家・・・
もうちょっと詳しく知りたいんですが、これ何をする仕事なんでしょうか？
設計だけするひとでしょうか？

まりもさん

個別に話するのではなく、あ～り～さんの言うとおり、
SQLで実施せず、オブジェクト指向言語側で実施する利点を。
を説明してもらえませんか？

なんか、今のままでは、まりもさんの目指す所がわからず、
結局、SQL軽視のイメージが先行している気がします。

そればっかりじゃ、なんなので、
>オブジェクト指向は、プロセス中心とデータの中心の見かたをプラスする形で発展
と、POA → DOA → OOA と進化してきたという見方が一般的ですが、
POA →　DOA 、　POA → OOA と独自進化したという見方もあります。
双方、切り口が違うだけで。
ちなみに、DOAでもデータの作成順という切り口から、振る舞いを
図に落とすことも可能ですよ。

以上、余談でした。

エンジン（RDB)なんて勝手に動くんだから、トランスミッション（O/Rマッパー）だけ勉強すりゃいいんだよ。
などとホザくヤツが車のスペシャリスト（技術者）名乗ってんじゃねえよ、って話だと思ってたんですがね。

脱線するなら場所変えてくれい。

うーん、根本的に話しがかみ合わないorz
別に尊敬を求めているわけではなくて、ただ単純にオブジェクト指向を知らないと指摘しているだけなんだけど・・・
振る舞いという単語だけ拘ったりもう支離滅裂です。
といっても、分析での振る舞いはオブジェクト指向プログラミングの事だけを指しているのではないから、指摘そのものが明後日の方向向いているけどね。
だから何度も分析・設計・実装を分けて考える必要があると言っているのに・・・
とてもじゃないけど、会話する気があるとは思えません。
データ（SQL）を無視する人がオブジェクト指向していると主張するなんて笑止千万とだけ言っておきましょう。
そこまでオブジェクト指向プログラミングの機能にだけ拘るのであれば、構造化プログラミングの産物であるif文も使ってはなりません。
そうしないと、理論が矛盾しています。
使うのであればSQLも使わなければおかしい。
どうぞ、オブジェクト指向プログラミングの機能だけを使って作業して下さいな。
それをプロの仕事というのかは疑問ですが・・・

それにしても、何かを言い訳にして逃げる人は、決まって保守性と言うんですよね・・・
勉強しないから保守性が低いなんて凄く恥ずかしい言い訳です。
言い訳を考えている時間があったらSQLを学習すればいいのにね・・・

学生さんや新人さんは言い訳を真に受けずにちゃんと学習しよう！
逃げていると、苦しい言い訳を考えなくてはならないようになりますよ。

/* -- */

これいいですね。区切りがはっきりとしていて。使わせてもらうようにしよう。

/* -- */

>炎上大好きだけど・・・
>・・・とりあえず、コメント長くて読み直しても最初のほう忘れちゃう。。。
そうなんですよ（＞＜）
コメントをツリー表示すること考えてくれないかなぁ・・

/* -- */ O/Rマッパについて。

O/Rマッパってどうあがいても、SQLを吐き出している部分に対する調整が必要だと思っているのですが、違うんだろうか？
っていうか、現実的に今現在時点でのO/RまっぱーはRDBへのデータアクセスが主体になってしまっているんだけど、本来はRDBという特定のDBMSに対する物とは違っていたと思うんですけど、どうなんでしょ？
記憶違いでしょうか？
発展途上なのでRDBMSに対する物になってしまっているという気がするんだけどなぁ・・
もともと、１つのプリミティブな型を複数のドメインで、また複数の名称で扱う為の仕組み、って覚えてたんですが。
これが違うですかね？
このように覚えていたので、
何故、SQL vs O/R とか　SQL vs OO とかなっちゃったのか、かなり謎なんです・・
（もちろん読み返しても最初の方が記憶から漏れるってのもあります）

え～、もう、話があさっての方向いてるよって事で無視してくれてもいんです　orz

ちょっと一言。

学校の入学試験は何のためにあるかというと、入学しても授業について来れない人をふるい落とすためにあります。
試験に通っても、途中でついて来れなかったらふるい落とすのが当たり前なのです。

高校生が、割り算・掛け算を知らないなら退学させたらいいのです。

「教えてくれない！」「落ちこぼれるのは先生が悪い！」ってのは、まぁ、モンスターペアレンツ・スチューデントの笑い話として、プロが同じこと言うのか……これがゆとりでしょうか。

忙しいのですが、あまりにあきれ果てたので……。

ちょっと一服ついでに、２つ前の記事から読み直してみました。
最初っからズレちゃってるのね(^^;
（なんだか懐かしい感じ・・）

生島さんへ
この連載で常に登場する、SQLを毛嫌いしている上流技術者ってこんな感じの人達ですか？

> インドリさん
こうもりさんこうもりさん。
とても嬉しそうですね。
でもその発言は必要ですか？
はたから見るとあなたはどちらの勢力にも属してませんが。

>高校生が、割り算・掛け算を知らないなら退学させたらいいのです。

デザイン力は飛び抜けているかも知れないのに？
統率力もアイデア力も飛び抜けているかも知れないのに？

複雑なシステムにおいてはSQLの位置づけは本当に
割り算・掛け算と同じかも知れませんよ？

他の能力が飛び抜けているなら他の場所に行けばいい。
SQLの重要さを説いているコラムにおいて、他の能力の有る無しやオブジェクト指向の議論など脱線でしかない。

脱線失礼。

SQLの重要性というより
保守効率をあげるSQLの可能性なら感じるんですけど。

線引きの話であればオブジェクト指向の議論はありでは？

と言っても、オブジェクト指向とは・・・は無駄ですね。

>まりもさん
改めて・・・私の前回のコメントのとおり説明をお願いいたします。
そうしないと双方先行イメージで話しているのと変化ありません。

このままじゃ、このコメント欄は相手に何かを聞く以前の段階です。

まりもさんは
オブジェクト指向の勉強とSQLの勉強と
基本的なデータ構造とアルゴリズムの勉強をされたらいいと思います。
まりもさんを攻撃しているひとだの、まりもさんと喧嘩するような
人はここにはいないと思います。親切にどうだめかを教えて
くれている人ばかりでしょう。

# まあ、読むに値する文だと思っているひともいないようですが。

うーん、どうもこー行き違いが多いような感じですが(^^;
まりもさんはーちと余分なセリフが多くって、それで反感買ってしまい、まりもさんの言いたいことが伝わらないんじゃないかなぁ。
おそらく、生島勘富さんの考え方に関しては大部分で賛同していると思うのですが、それも伝わってない感じかな？

まりもさんの趣旨は物凄くシンプルだと思うのですよ。
SQLに特化するプロが居れば、オブジェクト指向に特化するプロもいるのでは無いか？
そのようなプロがSQLに興味がないのではないか？
そして、まりもさん自身もそのようなプロを目指していると・・・

まぁ、SQL使えない人が増えていることを嘆いている生島勘富さんのとこに来ているわけですから、それ自体がケンカ売っているようなものかもしれませんがｗ
ただでさえ反感買いやすい立場なのに、表現の問題でさらに加速させたように感じます。

オブジェクト指向に対しての保守性の考察は、このコラムで語られています。

>オブジェクト指向言語 ＞ SQL ＞＞ 混在型

混在型があったので、列記されているのは、アプリケーションの形態だと錯覚してしまいましたが、これはイメージの話ですよねぇ。
良く見ればオブジェクト指向「言語」だったしｗ
で、現状は混在型が主であり、その混ぜ方がテクニックというかセンスというか、好み？
そーなると、保守性の優越ってのは人によって評価が違うから比べる意味が薄いですよねぇ。

あとはーパフォーマンスかな？
まりもさんの話を見ると、パフォーマンスが必要な場合はSQLを使う必要があると言われています。
逆に考えれば、パフォーマンスが不要な場合は、SQLである必要性が無いということだと思います。
もしくは、SQLが自動生成されようがなんだろうがパフォーマンスが出ていればSQL自体を覚えることが不要だということになります。
アセンブラの話がでたのは、そういう視点で、SQLをデータベースに対する機械語に近い感覚があるのではないかと思います。
実際には、その機械語であるSQLをお客ですら使っているってのが２つ前のコラムの趣旨だったわけですが(^^;

個人的には感覚として、SQLが機械語ってのは、大きくズレたものではないと思うのですよ。
そして、どのようなデータベースでも、どのような手段でも結果としてパフォーマンスが良ければいいんじゃないかなと。
人間からみて粗悪なSQLだろうが、お客の求めているパフォーマンスを実現できているのなら問題ないはずです。
そう、実現できていれば・・・なんですよねぇ。

まりもさんは、実現できているケースが多いと考えている、もしくは近い未来にそうなると判断しているのだと思います。
それを踏まえて、最初の話に戻ると、SQLを使う必要性は薄くなるんじゃないかな？
そして、完全にSQLを使わなくなれば、混在型から脱出でき、保守性も上がるってことですよねぇ。
これがオブジェクト指向に特化したプロの理想の形ですかね？

それに対し、生島勘富さんはさんざん駄目なケースを見ているわけですから、その時点で論外なんでしょうねぇ(^^;
オブジェクト指向で設計してパフォーマンスがでなかったらSQLを使う・・・じゃ駄目ってのも言ってますよねぇ。
問題なければ「SQLを！」と強く求めるコラムを作る必要もなかっただろうし(^^;
今回一番すれ違っている部分はここなんじゃないですかね、パフォーマンスに対する見積もりの違い。
特に、今現在でのね。

まー先のことはわからないですからねぇ。
もしかしたら数年後にはSQLを直接書くことは無くなるのかもしれませんし・・・
データベースの主流が表じゃなくて、オブジェクトになるかもしれませんし・・・これはーなり始めてるのかな？
そうなっても、レガシーなインターフェースとしてSQLは残るんでしょうねぇ。

何となくコメントを読んでいたら誤りに気付きました。
私の主旨から打ち間違いだと気付くと思うけど一応訂正しておきます。

誤：オブジェクト指向言語で処理したら保守性が悪い！
という言い訳は、技術的に成り立ちません。
正：SQLで処理したら保守性が悪い！
という言い訳は、技術的に成り立ちません。

SQLをちゃんと勉強しようって事です。
といっても、SQLを拒否する時点で、オブジェクト指向も習得していない事が明白です。
兎に角、両方勉強したらいいと思います。
それに、自分が嫌いという事で設計を曲げたら駄目です。
好き嫌いで技術を選択したらプロじゃありません。

ビガーです。こんばんは。

私は、オブジェクト指向大好きなので、オブジェクト指向の良さというか考え方について書きたいと思います。

言語の是非は置いといて、
システムの複雑度に応じて、利用する設計技術の方針を柔軟に定義することが重要であると思います。

以下のようなトランザクションスクリプト、テーブルモジュール、ドメインモデルで切り分けて設計方針とするのが現実的かと思います。
http://www.thinkit.co.jp/cert/article/0801/9/1/2.htm

実際のプロジェクトでは、ハイブリットになることが多い気がします。
トランザクションスクリプト＝サービス層の単位になり、ドメイン達を再利用する。
プレゼン層に一発でDataSetをバインドしたいならテーブルモジュールを使うとか。ado.netのCommandBuilderとかでSQL自動生成させる基盤とか作ったりしてましたわ。

インドリさんも云っていますけど、オブジェクト指向分析・設計がきちんと理解できていないとドメインモデルとかちゃんとしたのが描けないんですよね。
以下の書籍とかは、勉強になると思われます。(少なくとも私はなった)
結局は、振る舞いの粒度をどう考えるかが大事。データはDOA的発想とほぼ一緒だと考えています。

http://www.amazon.co.jp/%E5%AE%9F%E8%B7%B5UML-%E7%AC%AC3%E7%89%88-%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E5%88%86%E6%9E%90%E8%A8%AD%E8%A8%88%E3%81%A8%E5%8F%8D%E5%BE%A9%E5%9E%8B%E9%96%8B%E7%99%BA%E5%85%A5%E9%96%80-%E3%82%AF%E3%83%AC%E3%83%BC%E3%82%B0%E3%83%BB%E3%83%A9%E3%83%BC%E3%83%9E%E3%83%B3/dp/4894716828

納得感が得られたら、ユースケースについて学ぶとようやく実用レベルかと思います。
海底だの海面だの空だの出てきますが、結局機能の粒度と利用者の視点がどうオブジェクトとマッピングされるかということです。
http://www.amazon.co.jp/%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89%E2%80%95%E5%8A%B9%E6%9E%9C%E7%9A%84%E3%81%AA%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9%E3%81%AE%E6%9B%B8%E3%81%8D%E6%96%B9-OOP-Foundations-%E3%82%A2%E3%83%AA%E3%82%B9%E3%82%BF%E3%83%BC-%E3%82%B3%E3%83%BC%E3%83%90%E3%83%BC%E3%83%B3/dp/4798101273

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

何というか、機械語とSQLは全く違います。
ただ、上にいる人間が潰すという、それだけの話です。

素人にも出来るけれど、プロはそれ以下って、これぐらい恥ずかしいことはないと……。

出来ない素人以下が、そんなものダメだという納得できる根拠は見たことがない。
ただ、多数決では負けるけど、出来ない連中がプロを名乗ったら、本当に詐欺師です。

あれ・・・なぜ完全無視なのかしら。
けっこう、中立なんですけどね～

自分で読めってことか？読めないけど。
自分の意見ないのかな・・・批判ばかりだし。。。

とりあえず、自分の考えるメリットデメリットを提示するだけで
この喧嘩っぽいの収まるはずですがね～

相手に
「デメリットはなに？」とか
「業務ロジック組む勉強すべき」とか
だけ言い放っても・・・

で、自分は？
結論、どう思ってるんだよ・・・
なにがどう良くて業務ロジックはSQLじゃないんだよ・・・
SQLにするとどうNGなんだよ・・・

SQLにしようって思いはここに書かれているわけで、逆側から見た
意見が・・・ない。
相手の意見に反する部分だけじゃなくてさ、全体的な説明が必要だよマジで。

賛同もできないよ。

こんばんは。

一時期、ネットで流行ったネタですが。
SQL で数独ソルバーを作るとか。

Solving a Sudoku with 1 SQL-statement: the Model-clause
http://technology.amis.nl/blog/2066/solving-a-sudoku-with-1-sql-statement-the-model-clause

こういうのをみると、SQL が論理型プログラミング言語であるのを、あらためて実感しますね。

もう一点。

どうも「SQL」という言葉に、 手続き型言語（PL/SQL）を含めてないのが気になりますね。

例えば、Oracle 10g R2 以降には、線形代数ライブラリ（LAPACK）が入っていて、行列の固有値が計算できるとか。

LAPACK Driver Routines (LLS and Eigenvalue Problems) Subprograms :
http://download.oracle.com/docs/cd/E16338_01/appdev.112/e10577/u_nla.htm#CIAFGFFC

Oracle データベース って、ほとんど OS みたいなものなんですよね。JVM も動いてるし。

Oracle DatabaseでのJavaメソッドのコール
http://download.oracle.com/docs/cd/E16338_01/java.112/b56280/chthree.htm#CACJJHGI

業務ロジックが複雑な場合ストアドを命令型言語で書く機能がRDBMSにあります。
だから業務ロジックについて心配する事はありません。
しかしながら、複雑な業務ロジックを書きたい時は要注意！
データ整合性と一時的な手続きが混ざっている場合が多いです。
SQLで書くものはあくまでもデータ整合性に関する部分であり、ごちゃまぜにしたら駄目です。
データの安定性に着目してSQLで書くべきです。
一時的な手続きまで混ぜたら変更に弱いシステムになります。
その判断のためにもSQLとオブジェクト指向の学習が必要となります。
SQLはデータベースを学ぶ上で避けされません。
ちなみに、見掛け上のミスマッチを回避するためにオブジェクト指向DBへ行くと痛い目を見ます。
オブジェクト指向DBもかなり手ごわいです。
逃げの精神で習得できるほどやわじゃありません。
要するに、何の技術も嘗められないし、必要だと言う事ですね。
SQLに限らず、○○は保守性を下げると言い訳して逃げる上流技術者の話をよく聞きますが、自分の好き嫌いで潰さないでほしいですよね。
上で潰されると、お客様と下流が凄く困りますし、それは仕事をしているって言えません。
個人の分業は別にいいのですが、会社全体がSQLを知らないで選択肢を潰すのは、仕事の邪魔をしているのと同じです。
保守性を言い訳にしてサボっているのに、そこの会社の経営者は何をしているのだろう。

こー感覚的な問題なんですかねぇ。
プログラム言語側から見ると、SQLってデータベースを操作するための言語で、視点が

プログラム言語　－＞　SQL　－＞　データベース

ってな感じになるから、感覚的には低級言語なんだけど、これをデータベース側からみたり概要的なこと考えると高級言語になるんですよねぇ。
たぶん、データベースに触れてない人ほど低級言語のイメージを持つんじゃないかなぁ。
まぁ、それだから

>ただ、上にいる人間が潰すという、それだけの話です。

こうなるんでしょうが(^^;
開発のとっかかりが、データベースから始まる、もしくはデータベースの構造を考慮しながら行うようにしないとSQLが後に来ちゃうんですね。

>素人にも出来るけれど、プロはそれ以下って、これぐらい恥ずかしいことはないと……。

これももっともですよねぇ。
素人がSQLを使っている間は変わらないですね。
そして、ここまで広まっているとよほどのものが登場しない限りSQLは捨てられることはないですね。
まぁ、登場したとしても互換性を持つだろうから相当な年数使われ続けるのは予想されますね。

>ただ、多数決では負けるけど、出来ない連中がプロを名乗ったら、本当に詐欺師です。

評価されるのは全体のシステムですからねぇ、パフォーマンスに問題がなければお客も文句いわないでしょうし。
無視できるパフォーマンス差もあれば、話にならない差もあるんでしょうね。
前者を詐欺師というのは、厳しい感じですが(^^;

パフォーマンスはハード性能でも変化するから、話にならないほどの差ってのも減ってきているのかなぁ。
この間、有名サイトからサンプルソースをダウンロードしたら容量が3MBもあってなんじゃこりゃーとか思いました。
中身たら余分なファイルが入っていて実容量は9KBだったんですよｗ
こんなの昔だったら相当叩かれると思うのですが、今の時代だったら3MBのダウンロードって苦にならないですよねぇｗ
データベースも全てがRAMに収まるような巨大なRAM空間が用意されるような時代になると変わるんですかねぇ。

saki1208です。

いやいや、世の中にはハードウェアのパフォーマ
ンスアップの恩恵を受けることのできないおバカ
なSQLを書く技術者も沢山いますよ。

ハードウェアの入れ替えによって2時間掛かった
バッチが2〜3分になる物もあれば、10分が5分
なんてのもあります。

「速くなるんじゃなかったの?」なんて話に
なるとガッカリしますよね。
(お客さまへの最終的な納品物はシステム全体
ですから、内部のテストを通過している時点で
作った人間の責任ではないのですが…)
自分達で作った物ではそんなことになった
記憶がないので無性に腹が立ちます。

saki1208です。

補足です。
上の時間の話はもちろん同一システム内の話です。

あと、一ヶ月掛かる月次処理とか…
こちらは納品前に作り直して20分になりましたけどね。
さらにRDBMSのチューニングで2分にw

ビガーさん

最初の本は結構な値段しますねw
もう一度初心に戻って勉強しなおそうと思ってますので
購入したいと思っています。

しかし、他の方を馬鹿や使えないと罵ることができる程、できる方が
大勢いらっしゃるみたいでみなさんがうらやましいですわ。
私は、まだまだ未熟なのでとても他人を罵ることなんてできませんが、
いつかそう言えるほどのものを身に付けたいですね。

今までの時代を振り返ってみれば、ハードウェアの進化に伴って、要求されるデータ量がそれ以上に増えています。
「もっとコアを！」というやつです。
という事で、常にパフォーマンスを意識しなくてはなりません。
SQLでは数秒で終わる処理を数十分以上かかるように出来ますしね。
それにプロを名乗る以上、常に学習＆意識しないとなりません。
ツールに頼るだけならばエンドユーザーも出来ます。
ちなみに私はアセンブラも重要視しています。
それは、技術を軽視するのは、技術者を軽視するのと同じ行為だからです。
自分の仕事を否定してどうするのかな？

ストアドプロシージャの利用も
・SQL Server で TSQLを使いまくる
・Oracle で カーソルを操作するPL/SQLを粗製乱造する
ということを避けて作られていればそんなに苦労はしないと思うんですけどねぇ。

個人的にはテーブル、カラムに日本語を使ってる既存システムが憎い…。

Toインドリさん

今の話題の流れに関係ない上にデータ量とコア数はあまり関係ないです。
自論のぶち上げは自Blogでも作ってそこでやってください。

どの業界でもそうですが、常に勉強し続けるのは当然のことですね。
勉強し続けなければ駆逐され飯が食えなくなるので、皆さんは十分承知して
いるはずです。
勉強しないエンジニアっているんでしょうか・・・？

？？？コアってメモリの事だよ。
それに、パフォーマンスが重要だからSQLの学習が必要だと言っている事が分かっていないませんね。
話題の流れに関係ないのは貴方の方です。
人のコメントを読み取らずに、噛みつくためだけに書くのは止めよう。
もし分からないのであれば噛みつく前に聞こう。
それが社会人の常識です。

>勉強しないエンジニアっているんでしょうか・・・？

例えば、SQLを忌避する上流技術者は勉強していません。
勉強しないでも看板で飯を食っている人は沢山います。
もしいなければ、生島さんもこのコラムを書いていないでしょう。

>例えば、SQLを忌避する上流技術者は勉強していません。

生島さんも書いてますけど、私はこういう人にあったことが無いんですが、
勉強するしない以前の問題のような気がするなあ。
SQLやDB等の重要性を認識しておきながら自分自身の知識や意見が足りないのに
しない、または仕事で必要とわかっておきながら技術を勉強しない人といった
ほうがいいかな？
さすがにこんなエンジニアはいないでしょうけど（笑）。

>勉強しないでも看板で飯を食っている人は沢山います。

こういう人もいるんですかね・・・。
しかし、私の触れる世界が狭いのか単に気づいていないだけなのか、一度
出会ってみたいものですね。

saki1208です。

>SQLやDB等の重要性を認識しておきながら自分自身の知識や意見が足りないのに
>しない、または仕事で必要とわかっておきながら技術を勉強しない人といった
>ほうがいいかな？
>さすがにこんなエンジニアはいないでしょうけど（笑）。
たくさんいますw

>しかし、私の触れる世界が狭いのか単に気づいていないだけなのか、一度
>出会ってみたいものですね。
恵まれた環境ですよ。きっと。
会うだけなら害はないですが、一緒に仕事すると大変ですよ。

Toインドリさん
＞？？？コアってメモリの事だよ。
ソースを自logにでも明示お願いします。

変なの相手にしちゃったか･･･ちょっと後悔

また変な奴が議論の邪魔をしに来ましたね。
磁気コアメモリも知らないのですか？
「もっとコアを」というのは有名な逸話です。
ハードウェア技術者からしてみれば、どれ程メモリ容量を増やしても、ソフトウェア技術者はもっとメモリ容量が欲しいと言っているように受け取れます。
それ揶揄して「奴らはどれ程性能アップさせて常にもっとコアを！と言う」という風に言います。
不勉強な上に仲間とともに絡もうとするとは・・・
教えてあげたから、さっさと去って邪魔しないでください。
荒らしには困ったものだ。

>saki1208さん
速度に関しては駄目なプログラムほどハードの恩恵を受けるはずですよ。
こーハードの処理速度が２倍になったとするじゃないですか。
元の処理時間が、良いプログラムで１０、駄目なプログラムが１０００だとしますよね。
これが２倍になったとすると、良いプログラムが５、駄目なプログラムが５００じゃないですか。
良いプログラムは５しか向上しませんが、駄目なプログラムは５００も向上するとｗ

お客が求める速度が５００ならば、駄目なプログラムでもＯＫになるわけでｗ
この辺は、お客の求めるものでも変わるんだけど、ハード性能の向上でボーダーラインが甘くなるのは確かなんじゃないかな？
もちろん、良いプログラムのほうがボーラーラインを超えやすいので、駄目なプログラムを推奨するわけではないですｗ

速度を追い求めるのは、悪いことじゃないし、可能なら追い込みたいとこではあるんだけど・・・
一定以上はーこー作っている人の自己満足に陥りやすい部分でもあるのかなと(^^;
追い込む時間で別のこともできるわけですし・・・時間の使い方というのもスキルですよね。
実際問題として、他に足を引張る部分があるなら全体としての速度が上がらないわけでｗ

そそ、先の話で巨大なRAM空間と書いてしまいましたが、コレはスタンドアローンな考えですよねぇ。
ネットワークで考えるとRAM空間よりも回線速度のほうが足を引張りそうだしｗ

お客の満足度って速度も重要だけど、操作性とか見た目とかも大事ですよねぇ。
こー作った人の一番自信があるとこというか、がんばったところが評価されず、どうでもいいとこが評価されることもあるじゃないですかｗ
お客には作った奴が頑張ってるかどうかも関係ないので仕方がないのですが(^^;

>あと、一ヶ月掛かる月次処理とか…
>こちらは納品前に作り直して20分になりましたけどね。

変化ありすぎｗ
元が余程酷かったってことですかねぇ。
・・・というか、始めの仕様で通ってる事実のほうが驚きではありますが(^^;

まだ続いてるようで（笑）
コメント数が１００を突破していたのが個人的にツボでした（笑）

私はエンジニアライフでコラムを書いている事を、他社も含めてあちこちに伝えているんですよね。そして、先日ここのURLも伝えていました。『コメント欄が面白いですよ』という一文を添えて。

そしたら全員が鼻で笑っていました。（コラムの内容に対してではなく）

このコミックの主人公である人物の知名度は、不本意、もとい不名誉な形で全国区になったでしょう。

私なら、再起不能なくらいの恥をかいたと考え、もう＠ITに顔が出せないと考える（笑）

『厚顔無恥』という言葉をググればいいと思いました。

追記です。

鼻で笑っていた方の企業は、都内に本社を構える連結３０００人超の大手と、全国で２００００以上（これ言ったら特定されちゃうけど）の大手、さては500人超のエンドユーザー企業の方々です。何れも過去にプロジェクトを一緒にした人脈からの意見です。しかも其々が相当のポジションについている、いわゆる偉い人。

これを書くことは他人のふんどしで相撲をとるみたいで気が引けたのですが、要するに『大手もまだまだ捨てたもんじゃない』ってことですね＞生島さん

ビガーです。こんばんは。

>まりもさん

インドリさんの云っていること(分析とか設計)を私なりに解釈して、紹介したつもりでしたが、読んでもらえてないようで残念です。

>オブジェクト指向設計で業務ロジックを組む勉強もすべき。

これについてですが、あなたはどういうアプローチで今まで勉強してきていて、これから具体的にどういう勉強をしていくつもりで、それをどう具体的に実務に役立てようと考えているのですか？

漠然とした未来予想(これからはシステムが複雑になっていく一方だぁ的な)の上に勉強しても無意味ですよ。

それとあなたの云っているシステムの複雑さって具体的に何なんですかね？
基本的に複雑さを解消するのは、要件整理と分析・設計がカギを握るのです。

コラムとは無関係ですが・・・
エンジニアライフって人をバカにする書き込みが多くないですか？

>ちょりぽんさん

最低ですね・・・
これでも削除されないのかな、ここは。

理想的なアーキテクチャはいかにあるべきか、という話とは別に、受託開発の実務では、お客様の要求仕様で、アーキテクチャはある程度決まってくるわけでして。

RFP を読んでから、どの技術を使ってどう実現するか、を検討するのが現実なわけですから、AP サーバでも、RDBMS でも、どちらでもできる、というのが適切なスタンスでしょうね。

まず、RFP にありがちな項目として：

1) お客様の既存設備を使用すること

新しいハード・ソフトの導入は NG、というもの。既存設備の有効活用、という視点は良く入ってきますね。

生島 さんも既に述べられていたかと思いますが、RDBMS が既存設備に含まれている可能性は極めて高いでしょう。

.NET 、Java の AP サーバは、あるとすれば、どちらか一方でしょうね。どちらもなくて、C、Perl、PHP くらいしか使えない、という可能性もなきにしもあらず。

いわゆる、基幹系システムでよくあるのが：

2) 業務ロジックを他のシステム（他社製）からも使えるようにすること

他社製のシステムが、.NET、Java、C++ など、開発言語が多種多様で、まったく統一性がない、なんてのはありがち。しかし、RDBMS だけは同じサーバを使ってる可能性が高い。あちこちにデータが分散しているのでなければ、ですが。

まとめ：

業務システムの場合、「上物」がどんなプログラミング言語で作成されていても、最下層には必ず RDBMS がいますからね。必ず RDBMS でやるべき、とまでは思っていませんけど、要件を満たすための最後のカードとして、持っておくのが良いと思ってます。

当たり前ですが、お客様の提示する要件が満たせなければ、仕事がとれません。

> Ｓｏｄａさん

割り込みで失礼します。

> 速度に関しては駄目なプログラムほどハードの恩恵を受けるはずですよ。
> こーハードの処理速度が２倍になったとするじゃないですか。
> 元の処理時間が、良いプログラムで１０、駄目なプログラムが１０００だとしますよね。
> これが２倍になったとすると、良いプログラムが５、駄目なプログラムが５００じゃないですか。

アルゴリズムのパラドックスという話がありまして。簡単にいいますと、ハードの性能が向上すればするほど、プログラミングは難しくなる、というものです。

例えば、n 件のデータに対して、良いプログラムは、log n 回（対数の底は 2）のループで処理を終え、駄目なプログラムは n 回のループで処理を終えているとします。

n = 1024 のとき、良いプログラムは、10 回ループします。駄目なプログラムは 1024 回ループします。

さて、ハードの性能が劇的に向上したので、ユーザは、もっと大きなデータを使えると期待して、いきなり、n = 40 億 にしました。

良いプログラムは、約 32 回ループします。駄目なプログラムは 40 億回ループします。

なんと、良いプログラムと駄目なプログラムとの性能差が、32 対 40 億 に ！！

# なお数字は 2 の累乗から適当に選びました（1KB と 4GB）。計算が面倒だったので ^^)

saki1208です。

ちょっと書き方が悪かったなぁ。

確かにハードウェアの高性能化に関して、性能向上の伸び代は元々遅いプログラムの
方が数値上は大きい可能性が高いですね。

もちろん無制限に性能を追い求めてはいませんよ。
速いに超したことはありませんが、際限なく費用が掛けられる訳でもありませんし、
お客様との約束以上である必要もないと思います。
該当するプログラムの使用頻度や処理内容によって求められるレスポンスも変わっ
てきますしね。

ただ、キチンと理解してSQLを記述していれば最初から最適解により近い内容で記
述できると思います。

>変化ありすぎｗ
>元が余程酷かったってことですかねぇ。
>・・・というか、始めの仕様で通ってる事実のほうが驚きではありますが(^^;
別の部署で作っていたのでぎりぎりまで分からなかったんですよね。
内部の総合テストでダメだしして、テスト内容を確認したらその当時の対象件数
でテストしてなかったんですよ。
で、ソースを見せてもらったらガクブルなソースでしたw
まさにronさんが言ってるケースに該当します。
# マスタが増えるとループ回数が天文学的な数値になりその中で処理対象全件(数十
# 万件)から数百〜数千件を抽出するみたいな...

Ｓｏｄａ様

> コラムとは無関係ですが・・・
> エンジニアライフって人をバカにする書き込みが多くないですか？
>
> >ちょりぽんさん
>
> 最低ですね・・・
> これでも削除されないのかな、ここは。

二分するのは無理がありますが、仕事（技術も含め）に人間性が比例する仕事と、反比例していくような業種もあります。経験を積めば積むほど逆に歪みが浮かび上がってきてしまうことも。

皆様、素晴らしい方が多いですし、だから・・・というのも違うのですが、どうしてもそうなってしまうのかな、と思って読んでいました。

そういう業界なのかな・・と思ってしまいそうになっていましたが、そうでない視点をお持ちの方もいるということで、ほっといたしました。

>ronさん、saki1208さん

こー文字だけの世界でやりとりしてますからねぇ。
誰がどの辺までを追求しているのかってのはわかりにくいですね(^^;

データベース使うのにSQL知らなければ駄目と主張する人達は極限まで性能を追っているように見えてしまう。
その逆は、実用にならないレベルにまで速度を落としてまでも楽に書けるほうを選んでいるように見えてしまう。

ハードの話もボーダーラインが甘くなるという例でだしたつもりですが、立ち位置によって違う話にも見える。
人によっては、ハードの進化に頼ってソフトを進化させない話にも見えてしまう。

たぶんーなんですが、実際に駄目なプログラムだと判断するボーダーライン自体は、そう極端には変わらないんじゃないかなと思うのですよ。
ただ、他人が話しているボーダーラインが極端に違うように見えているだけなんじゃないかと。

そして、ボーダーラインを厳しく見積もっているほうが技術者として上。
甘く見積もっているほうが下という偏見が入り始めると・・・

体感として、エンジニアライフには技術絶対主義の臭いがするんです。
技術力があるほうが偉く、無いほうはバカにされて当たり前とね。
ただの偏見かもしれないのに、それが許されている・・・そんな感じを受けるのですよ。

具体的な数字が提示されれば、わかりやすいんですよねぇ。
お二人の話は、駄目プログラムの例としてわかりやすいし、多くの方が納得できると思います。
ハードの話は、実際の性能アップがソフトウェアの改良よりも効率が悪いことも多いので、現実的な話かと言われると微妙ですね。

ronさんとsaki1208さんが言っている事は、データベースエンジニアとして普通の範囲であり真理です。
それ程性能UPを目指しているわけではなくて、ごくごく普通の範囲で性能を言っておられます。
データベースエンジニアのチューニングとは、ディスクI/Oの最適化とかメモリヒット率の増加、インデックスの使い方などを意味します。
SQLでJOINの効率を意識するぐらいはスタートラインです。
今でもテラ単位のデータ量があったりするんだから、データベースを扱うものとしてSQLを学習するぐらいの事は当然です。
私たちはプロなんだからそれぐらいのボーダーラインから始めないと、お客様に笑われます。
下手したら「奴らはSQLを扱う能力が酷すぎるから、データベース周り以外を注文するよ。」とエンドユーザーに言われたりするかもしれません。
後、コメント欄では全てを教えられませんし、私はこれで商売しているんだから無料で全てを教えろと言われても困ります。
生島さんの口も悪いけど、そう言いたい気持ちが分かります。
それに、ビガーさんが良い説明をされている事ですしね。
みんな馬鹿にして書いているんじゃなくて、それじゃあプロやっていけないし、新人や学生が勘違いするかもしれないから、親切に忠告をしているのだと思います。

>車のスペシャリスト（運転手）を名乗っているんだから全然問題ないと思いますが。
運転手はエンドユーザでしょ。車を作る側の人間が、運転するだけじゃ余計だめですよ。

>体感として、エンジニアライフには技術絶対主義の臭いがするんです。
>技術力があるほうが偉く、無いほうはバカにされて当たり前とね。
技術的な話をする場合、基礎知識が必須です。エンジニアライフは初心者用ではないだけかなと思ってます。

生島社長へ、お大事に。

興味深く内容を見てたのですがびっくりしました。

> ちょりぽんさん
自分でおかしな事を書いている事に気付かないのですか？
そういう発言はやめた方がいいですよ。
「鼻で笑っていた方」達にそれこそ厚顔無恥だと笑われますよ。

高らかにコメントされていますが
むしろ鼻で笑う程度なら、捨ててもイイ人達なんではないでしょうか？（笑）

はじめまして。丹羽形ノアと申します。

>ちょりぽんさん
そしてあなたのそのコメントを投稿した瞬間、
あなた自身の信用を失墜させてしまったと
考えるのですが如何でしょう？

そんなこと書いてしまうと、
別のところで顧客のことを
同じように話している可能性も考えられますよね？
技術も大切ですが、信用も大切じゃないですか？

//----
すみません、初っ端から脱線してしまいました。
//----

オブジェクト指向やSQLうんぬんかんぬんよりも、
目の前にある課題から逃げないことが大切なんじゃないでしょうか？
ただ、このコラムの場合はRDBMSに関してが主な観点となっているため、
『(RDBMSを扱う上では)少なくとも初シスレベルのSQLは理解が必須』と
なっているに過ぎないですよね。

必要であれば、必要とされることをやる。
常にアンテナを張り、出来うる限りの最善の結果が出るように努力する。
根底はそれだけのことだと、私は、考えています。（もしかすると間違っているのかも知れませんが）

餅は餅屋なのでRDBMSという餅屋がある以上、
餅屋に米とか餡とかを求めるのは手間がかかるのでナンセンスで、
ただ餅屋の注文書に餅下さいって書けば、餅がすぐに貰えるので楽ですよね。

米とか餡とかが欲しい場合は、その専門の流通システムを持った業者(ODBMS等)に
任してしまえばいいです。
米だけが欲しいなら、そもそも業者に任せるよりも、自分で確保したほうがよくなるかもしれません。
RDBMSに頼らないなら、RDBMSの注文書(SQL)の書き方を覚える必要はないでしょうけど、
現状、RDBMSに関わる人が多いですよね。

必要であれば、必要とされることから逃げずにやるだけで、
必要でないならば、しなくてもよい。となると思います。
#その場合はRDBMSに対するSQLの必要性を語るこのコラムの主な対象者からは外れてしまうんでしょうけど
#(あ、すみません。本当の主な対象者は仕事を発注する側の方でしたね)

必要とされないことを、やってしまう、『勇み足』とかもあるので、色々とむつかしいですけどね。

//----
なんか、そのまま書いてるだけですね。私の知識・解釈等が至らずにずれてるかもしれませんが……
#『質問に対し、質問を繰り返す』ようじゃ、私もまだまだ修行が足りませんね。精進しないと

//----
生島さん、業界の変革、頑張って下さい。

>コラムとは無関係ですが・・・
>エンジニアライフって人をバカにする書き込みが多くないですか？

同意ですね。
セロさんの言うように基礎知識が必須、というのもわかりますが
それが馬鹿にしたり罵倒したりしてもいい理由にはならないかと。
#まりもさんもやりすぎとは思いますけどね。
#別のところで見かけた生島さんに対するメール切っとけばいい発言はいただけません。
#ピンポンダッシュされてインターホン切っとけよって開き直られたらイヤでしょ？ｗ

ちょりぽんさん>
鼻で笑われたのは自身かもしれませんよ。
「他人の悪いイメージを植え付ける人」なんだと思われてね。
ちょりぽんさんの知名度も上がったようでよかったですね。

インドリさん>
このようなことを書くと勉強不足とか言われそうですけど、
今のメモリと言えば半導体メモリですよね。磁気コアメモリは使われていません。
で、現状コアと言われればCPUのほうを想像することが多いと思います。
コア＝メモリとは必ずしも限らないということです。
#7743さんもコア数と言っていることからそちらを想像していますね。

そういう故事があるからそのまま書いたのかもしれませんが、
ググっても出てこないほど有名でもない、
また現状からミスリードしやすい言葉なのは予想がつくのだから
意味を取り違えただけで馬鹿にするのはいかがなものでしょう。
最初からメモリと言っていればよかったのでは？
何故ここまで7743さんに罵倒が飛ぶのか理解に苦しみます。
#仲間？とかよくわからないことも言っているし私怨ですか？

皆さん、こんにちは。

あまりついて行けてないのですけれど、堂々巡りの宗教論争になってしまいますね。

結局のところ、

【保守性】

　　　　オブジェクト指向言語 ＞ SQL ＞＞ 混在型

が成り立つかがまず一つ。

成り立つなら全部オブジェクト指向言語でケリがついてパフォーマンスが満たせるなら、保守性は上ですから開発工数とのトレードオフで選べばいい。

しかし、現状の多くのプロジェクトで混在型になっている。O/Rマッパーなどを使うと混在型にならざるを得ないのに、オブジェクト指向言語にした方が保守性がいいというのはおかしいでしょう。

というネタです。
全部のプロジェクトに当てはまるとも、何とも言ってないし、プロなら自身で判断すればいいじゃないですか。

ただし、次の記事にも書きましたが、初級シスアドレベルというのは、我々の業界を目指している高校生でも取れるレベルです。ネットワーク系とか組込系などでない限り、業界を目指す高校生にプロが負けたら、馬鹿と言われようと、カスと言われようと仕方がない。

そりゃ、石川遼選手のような例もあるけれど、初級シスアドを取った高校生って通算で何千人単位で居るのですから、プロとして本当にあってはならないことでしょう。

不思議なのは、まだアマチュアの石川遼選手に負けたプロは、相当に恥ずかしがったものです。相手が例え100年に1人の天才であったとしても。

しかし、何千人単位で出るというのは、ちょっとセンスが良いぐらいの普通人ですよ。それを恥ずかしいと思わず、堂々と書けるというのがIT業界の歪さを表している。

プロとしてのプライドがあって、同じくプロを名乗っている人間がそんなことを公言すると、一緒にされたら困るからプライドがある人ほど猛烈に腹立つし、口汚く罵ったとしても私は責める気にはなれない。

私の周りの非技術者は、初級シスアドレベルの人が堂々と反論していることに呆れていますから、多分、顧客はちょりぽんさんにつくと思いますわ。プライドの表れですからね。

掛け算、割り算と同じく、他の能力があっても足切りすべきレベルでしょう。プロとして、お互い尊重できるレベルの話じゃないですね。

こんにちは。ちょりぽんです。
まず、不適切なコメントを投稿したことをお詫び申し上げます。
申し訳御座いませんでした。

前提を書きますと、まりもさんとはコラムで一戦やらかしてます。その時も収拾がつかなくなり、私もイライラしてしまいました。結果、20件近いやりとりを削除して、コメント欄を凍結したという経緯があります。

ここは前々回のコラムから荒れてますが、上記の理由から私にとって予想通りでした。ですが、周囲からは多くの有用な助言が寄せられていたので、しばらく成り行きを見ていたんです。助言を受け止めて成長し、今回は円満に解決すればいいな、と。

以前、まりもさんは『気が付いたら周り中から攻撃されていたことが何度もある』と私に言いました。なので今回は何かを得たのだろうか？という視点を持ちながら見ていましたが、最後は当たり障りのない雑談で終わってしまい、アウトプットは何も無し。

上のコメントで私が「ケジメ」という単語を持ち出して決着を試みたのは、こういった事情からです。何らかのケジメがなければ、今後も同じような不毛な言い争いが巻き起こることは間違いないからです。

以上が苦しい言い訳です。
改めて、
昨日のコメントは私に100%の非があります。重ねてお詫び申し上げます。

>Sodaさん
最低だという言葉は受け止めます。ですが、
あなたが『最低だ』と私に言い放ったことと、
あなたが『特定個人を馬鹿にするサイトの常連』であることを、
頭の中でどのように帳尻合わせているのか教えてください。

生島さんこんにちは。

大変申し訳ないのですがコメントは途中長すぎて半分くらいしか読んでいません。

ですがとりあえず今回のエントリは非常に素直に受け止めることができました。
というか前回コメントしたときは敵対気味な発言でしたが、生島さんのおっしゃることの論旨には大枠で同意しています。

いつも非常に勉強になります。お金払わなくてすいません＾＾；

問題は生島さんのエントリを読むべき人が読んでない、あるいは見ても分からないっていう現実なんだよな～、とひしひし感じております。
裏を返せば、私みたいな連中がたとえ10万人興味深く見ても。短期的には何も変わらないという残念なお知らせなんですが・・・。

Toインドリさん
＞「もっとコアを」というのは有名な逸話です。
インドリさんの主張が正しいという証拠(ソース)を明示してください。

つっこんだ相手が紙上談兵で仮想敵が多数な人だとは思わなかった。
関わった事に反省せざるを得ない。

でも、どこかのコラムのコメントで話題に上ってたように、
一度ご本人を見てみたい人物だとも思います。実に興味深い。

何故こうも脱線して、粘着するのでしょうか？
やはり読会能力と常識がないようです。
自分が知らない事を理由に人を攻撃してくるから注意したのですが・・・
前にも言いましたが、貴方達が不勉強なのは私の責任ではありません。
これ以上人様のコメント欄に関係のない事が書かれるのは不本意ですので、
一言注意してから無視します。
【迷惑ですので関係のない話しを書きこまないでください】

ちょりぽんさんへ
その気持ち分かります。
私なんて、彼らの無知を理由に1年ぐらい誹謗中傷され続けています。
彼らにとって、自分が理解できない事は全て攻撃対象になるようです。
しかもその知識レベルが低すぎるし、手段を選ばないので厄介な集団です。
他者を誹謗中傷する事を生きがいにしているので、何を言っても無駄です。
最初から誰かを誹謗中傷する事が目的なのですから、向こうは会話する気なんてありません。
一言言って放置しておくのが得策です。
放置しておきましょう。

変換ミス

誤：読会能力
正：読解能力

【保守性】
SQL ＞ 混在型 ＞ オブジェクト指向言語

じゃないですかね？顧客から「画面はいらない」って言われたら
ずいぶんと楽なんじゃないかと。

とは言え、これが
複雑なSQL　だったり 膨大なSQL だったりするとちょっとどうかなぁってことに。

自分としては保守性を第一に考えるなら
「手に負えない技術は使うな」ですね。

>まりもさん
問いかけといて放置してすみません。
ご意見理解しました。

と、ここで言っているSQLはプロシージャやファンクションありですよね？
・・・あり・・・・ですよね？

で、あれば複雑であっても問題はないと思います。
「複雑」の意識が私と違うのかもしれませんね。
もちろん、私が「皆さん、iアプリ作ってから話せ」の際に言いましたが
問題がでる場合もあります。
生島さんも
「全部のプロジェクトに当てはまるとも、何とも言ってないし、プロなら自身で判断すればいいじゃないですか。」
と仰っていますし。

極論ですが、
オブジェクト指向言語 ＞ SQL ＞＞ 混在型
って
部長＞課長＞＞新人？
と同じで
新人だと慌てふためくからまぁ無理として、課長ができることは部長がやる必要はない！ということと同じ・・・いや、かなり極論すぎますね。
でも、インスピレーション的にはあっていると思います。
ってことで、SQLでできることをわざわざオブジェクト指向言語でやる必要は無く、オブジェクト指向言語側でしかできないことに注力を注げってことになりませんか？

あと、個人的な意見ですが（いつもそうですが・・・）
>>上記の解決策が「EclipseなどIDEや、そのプラグイン、はたまた設定や
>>アノテーションで簡単に自動生成できるから工数かからないよ！」になっ
>>ているんですが、そもそも論としてどうなんだろうな？と。
>基本的にIDEを使った作業というのはそうなるべきなのではないでしょうか。
これも私が前に発言していますが、ツールや機能などが便利に勝手にやるのはかまわないと思います。
が、意味不明で利用するのはどうか？ということではないでしょうか。

saki1208です。

SQLの複雑さ、長さ?ってのは確かに人それぞれの部分は
ありますがどの程度を複雑とするか、長いとするかって
ところに問題があるということではないですかね。
プロとして名乗っている以上、ある程度のレベルにはない
とダメってコトで…
作業範囲が比較的広い業種ですから全部を抑えるコトは無理
なこともありますが、ソレでも一般人が簡単に到達できる
レベルはダメでしょ。

刀の打てない刀鍛冶はいないと思います。
そう言うことです。

皆さま

お世話になっております。
＠IT自分戦略研究所 編集部の岑（みね）です。
エンジニアライフをご愛顧いただき、誠にありがとうございます。

編集部では、基本的に「コメント欄での活発な議論」を受け入れる方針です。
各人の主張はそれぞれ意義があるもので、異なる意見同士が交流することで、新しい意見や解決の糸口が見つかることがあるからです。

しかし、不毛な個人攻撃はお止めくださるようお願い申し上げます。
人への攻撃は、建設的な議論を何も生み出すことができません。

また、人となりについての憶測や断定もおやめください。
人柄や思考は、限られた文字数では判断することができないと思います。
おそらく、実際に話す機会があれば、いろいろな誤解が払拭されるのでしょう。
しかし、限られた文字数ではお互いに主張を伝えきれず、また表現がきつくなりがちです。
そのために「誤解が誤解を生む」負のパラレルに陥ってしまうのは、非常にもったいないことです。

つきましては、コメントを投稿する前に以下のことにご注意いただければ幸いです。

・投稿ボタンを押す前に、執筆した文章を最初から最後まで読み直す
・「読んでいる人（議論に加わらない人含む）が不快にならないかどうか」を検討する

文章を生業とする者として、日々「文字の強さ」を実感しております。
皆さまもいま一度、ご自身の「発言力の強さ」についてご一考いただければと思います。
何卒ご理解の程、よろしくお願い申し上げます。

再びこんにちは、丹羽形ノアです。

>ちょりぽんさん
誠実な謝罪が出来る人はかっこいいですね

売り言葉に買い言葉じゃないですけど、
お互いにかっこつけ、熱くなって平行線をたどるのも
傍から見るとみっともないですし、
そう考えると、ちょりぽんさんかっこいい

//----
宗教論の話に戻ると、どうせ宗教論なのだから、
互いに互いを批判しても批判で終わるし、
互いに、「へぇ、そんな考えなんだ」と
相手の考えを理解する、理解しようとすることが
一番の解決の近道じゃないかな、と思う今日この頃。
「でも」「だけど」は堂々巡りになる香りが……
#なので、生島さんも初め4行で「断り」を入れられてるんですね

//----
私の宗教の布教をするなら、混在型が一番近くなります。
みんながみんな、適地適材、必要な時に必要なパラダイムを使う。
これはスパゲッティーにするということではなく、
きちんとした論理に従い、「ここはこうだから、このパラダイムに基づいている」と
きっちり分かるように住み分けを行う。
新しい（誕生がという意味ではなく、自分にとってという意味で）パラダイムが
分からないなら、分かるようになるまでです。

//----
現場ではそんなこと言ってると、プロジェクトが進まなくなるので、
そこでの「流儀」を尊重して、作業を行うことを心がけていますけど……

//----
まだまだ経験を積んでいる段階ですが、
行動を起こさないと結果は出ないので、何れ行動にでます。

連投すみません。

>岑さん
>また、人となりについての憶測や断定もおやめください。

すみません。直後の私の投稿で憶測や断定が含まれていました。
反省し、以後繰り返すことの無い様、気をつけたいと思います。
誠に申し訳ございませんでした。

//----
上記の様なことが起きてしまったため、

>つきましては、コメントを投稿する前に以下のことにご注意いただければ幸いです。

>・投稿ボタンを押す前に、執筆した文章を最初から最後まで読み直す
>・「読んでいる人（議論に加わらない人含む）が不快にならないかどうか」を検討する

に加え、「投稿前に、新たな投稿が行われていないかの確認を行う」事を、
個人として実施したいと思います。

>ちょりぽんさん

こー凄く書きにくくなってるんですが(^^;

ちょりぽんさんとまりもさんの間に確執があったのは気がつきませんでした。
なるほど、前段階があったのなら感情的なことは、途中から見ている人とは、かなり異なりますね。
検索で引っかかるコラムは先ほど拝見しました。
続きの20件が削除されているってことですかね、そのコラムのやりとりを覚えていたら、私の表現も違うものになっていたかもしれません。

説明もせず、「最低」とだけ言ったことをお詫びします、どうもすみませんでした。
色々なトリガーを引いてしまったようで、申し訳ないです。
このコメント欄、そこまでの流れでも酷いと思う発言がいくつかあったのですが、ちょりぽんさんの発言が私の感情の限界を超えたようです。
説明をみると、特定個人を対象にした発言だったようですね。
私は、

>コメント数が１００を突破していたのが個人的にツボでした（笑）

この部分、そして、コミックと表現されている部分が許せなかったんですよ。
多くの人は真剣に会話をしていたと思います、私も真剣でした。
それをまとめて笑われているように見えたのです。

生島勘富さんも支持しているようなので、詳しい人からみたら、内容に関してはバカバカしいことなのかもしれません。
でもね、詳しくない人からみたら、それがわからずに真剣に会話しているんですよ。
お願いだから、その姿を笑う（もしくは、そう見える表現）のは止めて欲しいと思ったのです。

生島勘富さんは、なんだかんだ言って詳しく説明してくれるのでありがたいです。
バッサリ切ってるように見えて、手を差し伸べてくれる感じですかね。
私も自分が理解できている部分を、もっと上手く表現できれば良いのですが・・・難しいですねぇ。

罵倒に関しては、賛同できているかどうかで印象はかなり違うと思います。
今回、私は、罵倒側に深く賛同できていないので、より強く不快感を感じるんだと思います。
少なくとも、親切に皆が忠告しているようには見えなかった。
いや・・・忠告って時点で上からの視線ですよね(^^;

>頭の中でどのように帳尻合わせているのか教えてください。

うーん、これはですねぇ(^^;
私の中では、私が「ソレは違う」と思うことを言っているだけなんですよ。
場所は二次的というか、そこしかなかったというか、一方的に追い出されたというか(^^;

ちょりぽんさんのおっしゃりたいことは十分わかるんですが、説明すると長くなるというか・・・
場所は知っているんですよね？
ログは全て残っているので、中身を追っていただくのが一番なんですが・・・量が多いんだよなぁ(^^;
既に火の粉が飛んで来ているので、払いたいのですが、払うとその炎が大きくなるというか(^^;
ここで説明するのはアレなので、場所を用意していただければ、説明できるのですが(^^;;;;;

こんばんは。

今さらですが、このコラム本題について。
（すみません）

>【保守性】
> オブジェクト指向言語 ＞ SQL ＞＞ 混在型

「保守性」が「言語別のコードの読みやすさ」程度の話であるなら、私は気にしません。

どんな言語だろうと、うまい人が書いたコードは読みやすいですし、スパゲッティは読みにくい。弘法筆を選ばず、でしょう。混在型でも、うまい人が書いたコードなら、SQL がちゃんと読み取れるように書かれているはずです。

それこそプロなら、どんな言語でも読み書きできてしかるべき、ともいえますしね。

ストアドを使わない場合、私が保守性の面で気になるのは、SQL が AP サーバに置かれてしまうことですね。

例えば、システムが稼動して、1 年ほど運用したとします。その間、順調にデータが増え続けたため、アプリの一部機能にパフォーマンスの問題が発生しました。RDBMS の管理者機能を使って、原因となっている SQL 文を突き止めました。

さて、このときに、以下の 2 点が問題となります。

1) この SQL 文が、どのアプリのどのモジュールで使われているか、を即座に特定し修正できるか。

2) SQL 文を修正するとして、AP サーバを停止せずに SQL 文を入れ替えられるか。つまり、サービス停止は NG。

まず 1) について。

ストアドを使わない場合、手元にアプリのソースがないと無理ですし、どちらにせよ、修正するなら、開発元に連絡して対応してもらうことになりますよね。

ストアドになっていれば、RDBMS の中に SQL 文が入ってますから、コールスタックを見れば、どのストアドか特定できます。もちろん、ソースも RDBMS の中にありますから、直して入れ替えるのは、開発元でなくてもできますね。

2) について。

まあ、今どきの AP サーバなら、Hot Deploy できるでしょうけどね。ただ、アプリ単位で全部入れ替えになるんじゃないかな。その間に、ユーザがサービス使うのは、アプリの作りによっては、駄目な場合もあるのではないかと。

ストアドになっていれば、ストアドを入れ替えるだけです。

Oracle の場合、1 回目の呼び出しがエラーになりますけど（このタイミングで、セッションに新しいストアドがロードされる）。これは、アプリにエラーをキャッチしてもらって、リトライしてもらえば良いでしょう。

あるいは、ストアドにバージョン番号をつけておいて、シノニムでリンクしておくとかね。

stored_proc_1 <= stored_proc

のように。で、アプリからは、stored_proc の名前で呼んでおいてもらう。

このストアドを入れ替えるときには、stored_proc_2 を作って、

stored_proc_2 <= stored_proc

とする。こうすると、比較的安全に入れ替えられるんじゃないですかね。入れ替える前に、本番機で確認もできるでしょうし。

saki1208です。

>まりもさん
お客様の望んでいるものを作るのが仕事ですよ。
実際にものを作るとき、ハンコを押すだけの人しか現場に出てこないのでしょうか?
現場の担当者の方ももちろん全員ではなく代表者ですが出てきますよね。

その方たちから要件を聞き出して設計し、承認を得た上でしかものは作れません。
もちろんより良い実現手段があれば提案しますが...
本当に望まれているが要件に含まれていないのであれば、それはお客様内部の問題
である可能性もあります。
要件として挙がってくるよう徹底的にお客様内部で検討してもらうしか無いんじゃ
ないですかね。
# 立場上の問題もあるかもしれませんが、本当に必要なら説得するべきなんですよ。
# それができないということは、本当に必要ではないか、気持ちが足りないかのどち
# らかです

>でも、我々が作ったソフトが、お客様に本当に役に立つには、
>実際にソフトを使う人を思い浮かべなくてはならないのではないでしょうか。
これをやらずに設計する人は残念ながら多いです。私の周りにも当然います。
ただ、実際に作る時点ではなく、設計する段階からある程度考慮していないとダメで
はないでしょうか。
そもそも今でも一般的にはウォーターフォールで開発していることが多いとは思いま
すが、アジャイルで開発するためにはお客様から了承をいただいた上でそのように契
約する必要があります。
理想論だけを述べるので無く、あなた自身、周りの方とちゃんと会話して受け売りで
はないあなた自身の言葉で説得していかなければあなたの望むように開発することは
できないのです。

>基本的に私は、その視点でものを考える習慣になっています。
>つまりこのソフトが要件を満たすかじゃなくて、使いやすいかどうか。
>使ったら仕事が楽になって、同じ時間でより会社に貢献できるるようになるかどう
>か。
お客様の仕事は楽になるでしょうね。しかし、要件以上の機能を盛り込んであふれた
工数分の費用は誰が支払うのでしょうか?お客様ですよね。要件の範囲内で最大限に
使い易くなるよう設計/作成する義務はありますしそうすべきですが、要求されてい
る以上の機能を盛り込んでも誰も喜びません。
# 限られた予算の範囲内で最善の仕事をするのもプロとしての任務ですよ。

それはただの自己満足です。

「こうした方が使い易い!!」と言う案があるならば、設計者やプロジェクトのリーダ
ーと徹底的に議論するべきです。
# あなたが設計しているのであれば、そのように設計し、キチンと承認が得られれば
# 問題ないんじゃないですかね。

>そういう視点で考えると、
>今の業務ソフトは今のままではいけないと思うのですが。
これには同意します。

あと大きな誤解をしているようですが...
>また、使ってみて悪いところをすぐ直せないなんて話になりません。
>もうテーブル設計が固まったから直せません、なんてことは許されないです。
>それを達成するためには、オブジェクト指向設計を中心に持ってきて、アジャイルに近い開発をする必要があります。
誰も否定していませんが...
生島さんの持論では「テーブル設計は実装の後に」と言われているのをご存知無い
のでしょうか。

saki1208さんへ
誘いに乗ったら相手の思う壺です。
矛盾に満ちた事をいいながら、さぞかしお客様の事を考えているかのように振る舞い、習得していないオブジェクト指向という単語を持ち出してくるので気持ち悪いのは分かりますが無視するのが得策です。
この人がオブジェクト指向を習得しておらず、SQLから逃げるor場を炎上させようとしているのが明白なので放置しましょう。

saki1208です。

だんだん馬鹿らしくなってきた。

斜め読みせずにちゃんと文脈を追って、文章全体を見て欲しいなぁ。
>>お客様の望んでいるものを作るのが仕事ですよ。
>
>だから。
>それはみんな考えているのであって、自分だけが考えているという前提に立つのはよろしくないです。
>
>相手は考えていなくて自分は考えているんだ、という前提に立つと、
>あげあし取りになって不毛になってしまいますよ。
文章全体を読んで反論するならこんな内容にならないと思うんだけど...

>># 立場上の問題もあるかもしれませんが、本当に必要なら説得するべきなんですよ。
これはお客様サイドの話をしているのであって、我々業界人のことを言っている訳では
ないのですが...
お客様の側においてもちゃんと要件の整理をしてもらわないとダメってことです。
使うのはお偉方じゃなくて現場の人間なんですから。
費用の問題から却下されたり、先送りされる要件がでてくるかもしれないでしょ。
上に書いたのはそういった部分の話ですよ。

システム屋としてやるべきことはこっち!!
>「こうした方が使い易い!!」と言う案があるならば、設計者やプロジェクトのリーダ
>ーと徹底的に議論するべきです。
># あなたが設計しているのであれば、そのように設計し、キチンと承認が得られれば
># 問題ないんじゃないですかね。

>>生島さんの持論では「テーブル設計は実装の後に」と言われているのをご存知無い
>のでしょうか。
>
>あとはこのくらいかな。
>つまり、それが終わったあとは直せないんですよね？
>実装のあとってのは、運用が始まったあとじゃないですよね？
>まさにその開発手法を念頭に置いて言っていますが。
なんでできないと思うのですか?
できるように設計すればいいんじゃないんですか?

反論のための反論はあまりよろしくないですよ。
あと、ココでコメントを返してくれる人が皆一様に似たようなことを言うのはなぜか
もう少し真剣に考えましょう。

全レス返信とかイタズラではなくすでに嫌がらせレベルですな。

>まりもさん

まずは、直接のコメント部分の返信で、

>意見の違いはあるでしょうが、比べることができないとは思えません。

処理している内容、得意不得意、好みかどうかなど、違いが大きすぎるのですよ。
評価＝その人のコストです。
このような内容は、宗教論争と呼ばれ、比較自体が争いの元になるだけです。

>たとえば社内システムの画面系、という条件でダメなケースってのはどれだけあるものでしょうか。

パフォーマンスの話は、データベースを扱う時の話ですので、それ以外の話は関係ないですよね。

さて、大量のコメントをアップされていますが、

>生島勘富 2009年12月11日 (金) 12:06
>成り立つなら全部オブジェクト指向言語でケリがついてパフォーマンスが満たせるなら、保守性は上ですから開発工数とのトレードオフで選べばいい。

このコメントにより、生島勘富のお話は主にパフォーマンスが満たされない場合の話だったことがわかります。
そのため、それ以外ケースの話は無関係な話ですね。
残念ながら、まりもさんのコメントの多くは無関係な話になると思います。
アップするなら、そのコメントがアップされる前にすべきでしたね。

今回一番問題なのは、まりもさんの会話の仕方であると思います。
余分な一言、会話の姿勢など、多くの人の反感を買っていると思います。
今回の大量コメントアップも多くの反感を買うでしょう。

初期段階で技術力や読解力を疑われてお怒りなのはわかりますが・・・
それを言い返している時点で、お互い様になるだけでしょう。
むしろ、会話として成り立たなくなることが多いと思います。
どんなに素晴らしい意見でも、聞いて貰えなかったり、理解してもらえなかったらゴミになります。

技術力や読解力を疑う側には疑うだけの根拠があるのでしょう。
それが誤解であるならば、その根拠に対して違うことを説明すればよいと思います。
その説明には、相手を罵倒する言葉や煽る言葉は不要ですよね。

生島勘富さんは、オブジェクト指向を否定していないことや、パフォーマンスをクリアしているなら問題ないことも説明していますよね？
それを踏まえた上で、素人に負けるのは恥ずかしいことだと言っているだけなんですよねぇ。
こーコメントつける別の方々の意見を見ていることもあるせいなのか、前提部分がぼやけて見えるのかなぁ。

つーことは、SQLを熟知した人が、なんらかの理由でSQLを使わないほうが良いと説明しなければ反論にはならないってことですねぇ。
パフォーマンスをクリアできていないケースが多いのか少ないのか、ちとわかりませんがー
多数決で負けるって話もあったので、クリアできないケースは減ってきているのかな？
まぁ、数が少なくても、そんなプログラムを組んでいる奴がプロを名乗ってるのが許せないという話には同意したいと思います。

>> Oracle データベース って、ほとんど OS みたいなものなんですよね。JVM も動いてるし。

> .NET Frameworkも動いているんですよね。
> しかもなぜかSQL Serverより先行して。

サーバサイドの話なんですけど。
Unix (Solaris OS) で .NET Framework が動くとは、不勉強で知りませんでした。

# Linux の Mono プロジェクトとか？ あれって、そこまで使えるレベルなの？

> で。それを使うなら、全然問題ないのですが。
> オブジェクト指向設計を行った、クラスが全部使えるわけですから。

当然、インターフェイスとしては、SQL から使う、ということになるわけですけどね。

> Ｓｏｄａ さん

> つーことは、SQLを熟知した人が、なんらかの理由でSQLを使わないほうが良いと説明しなければ反論にはならないってことですねぇ。

RDBMS を使うなら、SQL を使わない、という選択肢はないですからねえ。

RDBMS 標準搭載の SQL では良い効率が出せない、というケースでは、C 言語で RDBMS の SQL を拡張する、って話になりますかね。OSS の RDBMS なら当然できますし、Oracle にも C 言語で作った拡張を呼ぶ機能（extproc）はあります。

全文検索エンジンを RDBMS に載せるとか、Geometric 情報の検索とか、独自の検索エンジンを使いたい場合。

まあ、最近の RDBMS には大抵のものは標準搭載されてますけど。

# 私は、お客様の要求で、RDBMS 上で行列計算（線形代数）をやらなければならなくなって、調べたら、Oracle 10gR2 に標準搭載されていてびっくりしました。Fortran のコードを (LAPACK) を C 言語にリンクして、拡張作らないと駄目かと覚悟してましたが。

みんな、挑発に乗りすぎですよ。
どうみてもまともに会話する気がない人を相手にしても無駄です。
炎上魔は冷静にスルーした方が得策だと思います。

>まりもさん
>生島さんに言うべきことです。

いいえ、コメントの中で生島勘富さんは比較する必要がないことを説明されています。
また、この話は、私とまりもさんの間に発生しているものだと認識しています。

>データベースを扱う社内システムの話です。

いいえ、その中でもデータベースとのやり取り部分だけの話です。
なぜなら、それ以外の部分にSQLは無関係だからです。

>おもに反論しているのは馬鹿だカスだのほうなので、あまり意味がないです。

反論するには、前提条件を揃える必要があります。

パフォーマンスが必要な場面にSQLをろくに知らない奴がプログラムをしてプロを名乗っている。
SQL自体は素人でも使っているものだ！
こんなのがプロと名乗るのは許せない！

結果として、このようなわかりやすい単純な話だと思います。
これに反論するには、未来の話ではなく、今現在の話として「パフォーマンスが必要な時にでもSQLの知識に乏しくても良い」と主張する必要があるのではないですか？

>あるので、人とのコミュニケーションはかなり慎重に行っています。

残念ながら、まだ慎重さが足りないのだと思います。
人が違うのに同じことが繰り返される場合、原因はどのにあると思いますか？
ネットは思っているよりも公平なんですよ、周りが悪い可能性よりも自分が悪い可能性が遥かに高いです。

>相手の言うことを無視しないと礼儀に反するという風習がネット上にあるのは知ってはいますが、

その状況により異なるでしょう。
まりもさんにとって、誠実に対応したつもりでも、周りからはそう見えない場面もあります。
今回の場合、内容の大半は前提が異なっているものだと思います。
先に書いたように、アップするタイミングが早ければ問題なかったと思います。
しかし、今回は遅かったのですよ。

>言い返してはいません。
>あなたの判断方法に従えば、こういうことも言える、という文脈は必ず付けているはずです。それも生島さんに限っていたつもりです。

そういう文脈をつけて言い返しているではないですか。
この手の手法はよくあることなんですがー相手の判断方法を誤読していた場合、なんの意味もありません。
むしろ、わかっていないことを露呈することになります。
仮に誤読ではなかったとしても、感情的に相手を煽ることになるでしょう。
そして、まりもさん自身の考察が含まれないので、まりもさんの考えも相手に伝わりにくいでしょう。

>馬鹿だカスだ恥ずかしくないかと言っている人間が原因なのではないですか？

罵倒が肯定されるかどうかは、表現の程度や、賛同者の数によって異なるでしょう。
先にも書きましたがネットは思っているよりも公平です。
罵倒に対して苦言を言う人が現れないのであれば、多くの方が同じようなことを感じているのだと判断したほうが良いです。
行き過ぎた表現は、別の方が注意する可能性が高いのです。
誰も注意しないということは、少なくともその場では、その罵倒は肯定されるものなんでしょう。

罵倒という行為を肯定するわけではありませんが、人間は感情をもっているので全てを否定することもできないと思います。

>自分が公平に書いていると認識していますか？

私が公平である必要性はないでしょう。
私は私の判断で、発言しているだけです。
多くの人がそうしていると思いますし、だからこそ、ネットは思っているよりも公平になってしまうのです。

>これはかなり誹謗中傷だと言えるんじゃないですかね？

受け止め方は人それぞれなので、そう思ったということ自体を否定することはできません。
私の発言が間違っていると思う方がいれば、間違っているというコメントが付くだけです。
ネットでの書き込みは文字だけの世界です。
書き込んだ人の意図とはまったく違った意図に受け止められる場合もあります。
全ては、読む人の判断です、読む人の読解力を疑うのは簡単ですが・・・
まずは自分の書き込みが誤解を与えるものかどうかですね。

>矛盾している部分について反論しているわけですが。
>そのへんについてどう考えたうえで、このコメントを書いていますか？

私は、矛盾していないと判断しています。
まりもさんの書き込みは、「なんで正しいはずの私をわかってくれないの？」に溢れているように見えます。
まりもさんは罵倒を受けた被害者でもありますが、罵倒を誘発した加害者でもあるのですよ。
多くの文章で相手の感情をさかなでするセリフが混ざっているように見えます。
私は、それが余計なセリフだと思っています。
自分の文章を自分が言われたものだとして見て、そう思わないということならば、私と感覚が大きく異なるのでしょう。

ＰＳ．
長々と、本編に関係のないコメントを上げることをお詫びします。

誹謗中傷サイトの住人が言うセリフではないと思いますが・・・
人に言う前に自分がしてきた事を考えた方がよろしいかと思います。
それと、数さえ揃えればいいという理論が垣間見えて気味が悪いですね。
数の暴力に頼りブログを炎上させる人らしい理論ですがね。
まりもさんが相手の文章をまともに読まずにこうやっている事を、
貴方はもう一年ぐらいまりもさんと同じことをやっています。
「相手の文章をちゃんと読む」と「社会人としての礼儀をわきまえる」という当たり前の事をしているのかが重要な点です。
当たり前の事をしていれば、誹謗中傷を生業としている異常な人以外は普通に返事をしてくれます。
まりもさんの事をとやかく言う前に、同じことをしていると把握して下さい。
相手の文章をよく読む、ある程度礼儀をわきまえる、誤読・妄想・曲解で人を判断しないでちゃんと確認をするの三つをして下さい。

コメントの事についての要望
大人の社交場ですので荒らし対策をして頂きたいです。
せっかくいいコラムがあって、エンジニア達と議論を健全に楽しみたくても、
荒らしが乱入する事により議論やコラムが台無しになります。
このまま、荒らしを放置しておくと「殆ど全員がコラム欄を閉じる」なんて事になりかねません。
このコラムはエンジニア同士の交流を楽しむためのものですから、健全な交流を促進するために環境を整備して頂きたいと私は思います。

ビガーです。こんにちは。

生島さんに迷惑＆残念すぎるので、これで最後にします。

>「パターンオブエンタープライズアプリケーションアーキテクチャ」は読みましたよ。

読んで何を理解してのかわかりませんが、少なくとも

>ドメインを使うなら、単にドメインモデル+GOFのファサードパターンでしょう。

上記のような発言をされている限り、本質的なことはまったく理解できていない。
重要なのは、ドメイン構築の仕方だと云っているんですよ。トランザクションスクリプトとドメインモデルのドメインの粒度は、根本的に異なる。
なぜ異なるかはは、開発アプローチ(開発者スキル、企業文化等々)が違うから。

>だからまあ、長所も欠点もすでに書籍で言及されている通りなんですよね。

で、現場で適用して本の通りでしたで終わりですか。それともお遊びでの感想ですかね。

>遭遇した例はあまり挙げないほうがよさそうだな。守秘義務とか。

守秘義務にあたらないように書けばいいだけでしょ。その時点でオブジェクト指向で必須な抽象化能力がないと公言していることと同じですね。

>「パターンオブエンタープライズアプリケーションアーキテクチャ」に乗っていた、
>データベース関連以外のパターンを使うような場面を思い描いていただければいいと思いますが。

これ具体的に何を指しているですかね？「具体的に」お願いしますよ。

ちなみに私からの返信はもうないので、質問型はやめてくださいね。

いつも楽しみにしている生島氏のコラムが台無しになってしまい、
残念でなりません…。

まりもさん

> 生島さんのコラムは、反論が来たら台無しになるような代物なんですか？
> 私はそうは思わないですが。
> そう思う人もいるんですね。

まりもさんが過剰な投稿をすることによって
まりもさん以外の意味のある反論が来なくなるのは問題です。

生島さんもやめてくれと書いているし、あなたの知人も
やめたほうがよいと忠告しています。
別のところに好きなだけ書いて、URLを張るくらいにしたらいいでしょう。

「数少ない知人にここを紹介してみたら、
皆さん悪質なのに捕まったね。
なんで逃げずに続けているの、とか言われます。」
「私のネット上の知人に見せたら、みんな生島さんの性格が悪いんで話しても無駄だって言ってますけど。」

ビガーです。すみません、本当の最後の最後にこれだけ。

>トランザクションスクリプトの原典と違うことを言っていて。

違うこととは、ロジックとドメインをごっちゃにして考えているとかそんなレベルなんでしょうね。たぶん、あなたはその本当の意味さえもわかっていないんでしょうけど。

書籍に書いていることをどう自分の血肉に変えるか、という観点がゼロのようですね。

ひがさんがいいことを書いているので、本当の意味の勉強(自分の血肉に変えるってことね)を始めたらどうでしょうか。
(他人の意見じゃなく自分の意見を言えよ、とか言い出すんだろうなぁ、生島さんの迷惑になるから文を短くするために引用しているんですがね)
http://d.hatena.ne.jp/higayasuo/20080519/1211183826

> まりも さん

こんばんは。

> サーバーの話は出ずに、Oracleの話でしたよね。

Windows だとも言ってませんねえ。

お客様にもそう言うんですか？ お客様に「うちは Oracle 使ってるから」って言われて、.NET で一所懸命作ってもっていったら、OS が Unix だった、という光景が思い浮かびましたが。

> 生島さんが、そうしないと言っているからです。
> 画面をアジャイルで開発して、それでテーブル設計が固まったあとでウォーターフォールでストアドプロシージャを開発する、って言ってますよね。

「チームを分ける」と仰っていますから、画面と DB（ストアド含む）、並行して開発でしょ。

チームを 2 つに分けておいて、画面チームが開発している間、DB チームは待ち惚けですか？ そんなこと、どこで仰ってます？

> パフォーマンスが必要ない部分についてもそう言っているから問題なのです。
> パフォーマンスが必要な部分のみの話だというなら、画面系の業務ロジックはO/Rマッパーの向こう側に任せても問題ないはずです。

「パフォーマンスが必要ない部分」であるかどうかを、どこでどうやって判断するんでしょう？ 総合テストですか？ 本番稼動後の運用フェーズですか？

> 画面に表示できるだけのデータの取得で、パフォーマンスが問題になりますか？

例えば、1 億件のデータから、10 件のデータを抽出して画面に表示します。パフォーマンスは問題になりませんか？

スゴイ事になってますね…　続けるなら場所を移しませんか？
コラムと乖離する議論までコメント欄でするのは如何なものかと。

幸い＠ITには会議室なるものもありますよ。
（ページ最下部のfooter↓にリンクがあります。）

そして、再度岑さんのコメントをペタリ。
http://el.jibun.atmarkit.co.jp/g1sys/2009/12/post-af96.html#comment-30697935

> まりも さん

> 全般的に。
> 私に何が言いたいので？
> 反論したいの？

まりも さんの、

> 実際に技術内容についての話を最初に始めたほうが有意義なんじゃないですかね。

を受けて、具体的に技術内容の話を確認してみたわけですよ。
なんか、流されちゃいましたが。

もう、この辺で終わりにします。
すみません、生島さん、皆様。
おやすみなさい。

>パフォーマンスなんて開発者の自己満足です。
この発言の時点で素人以下の、開発チームにとって害にしかならない方だとよく分かりました。
生島様、皆様、お疲れ様でした。

みなさま、こんにちは。

どうしても、本文と関係ない方向にコメント欄の議論が向かい、収拾がつかなくなっているので、一旦、一部の方のコメントを非表示にさせていただきました。

個別見直して非表示にしたいところですが、時間がないので、皆様にメールを差し上げております。

ご確認の上、非表示にされたい方はメールにてご連絡ください。

反対意見は大変結構です。
勉強になりますが、ちゃんと本文を理解してから反対意見を述べるようにして頂ければ幸いです。

何卒、よろしくお願いいたします。

おもしろいので、仕事をするふりして読んでました。

あくまで個人的な意見ですが、どっちもどっちという気がします。
SQLマンセーな生島さんの考え方も排他的で、ちょっと鼻につくし、まりもさんのコメントの方向も少し感情的で問題があったように思います。

個人的には、SQL やPL/SQL とかで大事な業務ロジックを書こうとは思いませんけどね。

だいたい、RDBMS の限界ってそろそろ見えてきていると思うので、将来的なことを考えるとSQL ばかり勉強するのはどうなんだろうな、というか。
近い将来、Bigtable のような、key-valueストア型が主流になったとき、SQL でしか業務ロジック書けないと困るような。

と思ったら、会議室の方に移動してたんですね。そっちも覗いてくることにします。

うちには、Javaラーの介入を一切排除したWEBシステム（Javaコード部の自動生成ツール）とJavaラーが入らないとどーしょーもないWEBシステムとあるのですが、前者のシステムは、SQL/COBOLオンリーで全ての業務ロジックをまかなっていますね。
人件費は、Javaラー＞コボラー＞SQLラー＞エクセラー　ですから、長い目で見れば、初期投資はでかかったのでしょうけど、自動生成ツールによるJavaラー排除はプロジェクトとしてうまくいったんでしょうね。

＞DBサーバで処理させるように設計を進めていけば、ビジネスロジックの
＞大半はDBサーバに入ります。オブジェクト指向言語が行うのはユーザイ
＞ンターフェースの部分で、DBに関わる部分は完全なブラックボックスと
＞して考える。基準はユーザオペレーションに対して、基本的に1回のDB
＞アクセスで済むように（明細の更新は明細数回送ってもよいと思うけれ
＞ど）と考えて設計すればよいのです。

これは大賛成。
Javaラーの私としては、仕事が無くなる危機ｗだけど、、、

まりもさんの書き込みは、（会議室にもあるようですが、経過を知る上で）残して頂きたかったです。

残念でなりません。

＞まりもさんの書き込みは、（会議室にもあるようですが、経過を知る上で）残して頂きたかったです。

同感です。
ここを読んでから、「常識のライン」を読んでいましたが、どうもコメントの流れがうまくつながらないのをおかしいと思っていたら、削除されていたんですね。
後から読むと、よくわからないです。
まあ、コラムを読んでほしいのであって、コメントを読んでほしいわけではないのでしょうが。

すみません。質問なんですが、本文中の

>※ なぜ、WHERE 売価 <> fn_標準価格（得意先コード, 商品コード）
>　　としてないか分かりますか？

の部分が分かりません。

レベルの低すぎる質問で申し訳ありませんが、
よろしくお願いいたします。

SE3年目さん、おはようございます。

SQLは
FROM → WHERE（JOIN） → GROUP BY → HAVING → SELECT → ORDER BY
の順で個別に実行されます。

WHERE句で
　　　　売価 <> fn_標準価格（得意先コード, 商品コード）
とすると、fn_標準価格が（FROM JOIN と他のWHERE条件で絞り込まれた後の）全レコード数回実行されます。

その後で、SELECT句で対象となったレコード数回、fn_標準価格が実行され、結果がメモリーに展開されます。

サブクエリを使うと、全レコード数回実行された結果がメモリーに展開されて、サブクエリの親のクエリは、展開されたメモリー上で読み飛ばし処理だけを行います。

1回実行するたびに10テーブルにアクセスする関数「fn_標準価格」の実行回数を抑えることが、システム全体のコストを下げれるので、記述に大差がないので、そちらの方が有利と私は判断したわけです。

ここは、FROM句に書くサブクエリと、SELECT句に書くサブクエリ（相関サブクエリ）とどちらを選ぶかというところにも関連してきますけれど……。

OO言語でも、再利用や読みやすさを優先し過ぎるとパフォーマンスの劣化を起こします。

実際の現場では、読み易さとトレードオフするために
　　　　WHERE 売価 <> fn_標準価格（得意先コード, 商品コード）
を試して、遅いときはサブクエリのパターンに書き換えます。
大差ないから、将来、チューニングが必要になってから書き換えでも問題ない。

ところが、OO言語で同じようにパフォーマンスをみてチューニングするには、数種類は最低書いて、さらに遅いときはSQLで処理するパターンも考えないといけないわけですよね。

単純に決め打ちのコーディング量でも、OO言語では数倍の工数が掛かりますが、パフォーマンスまでちゃんと見たら、しゃれにならない工数の差になります。

初期段階で、どの程度パフォーマンスまで考慮して作るかということになるけれど……。

OO言語で一番単純になるように作った場合と、SQLで一番単純になるように作った場合の生産性が

　　　　OO言語 ＞ SQL

だったら、OO言語をデフォルトに考えて、遅いときにSQLは正しいけれど

　　　　OO言語 ＜＜ SQL

ですからね。

OO言語でやるメリットはカスに仕事を与えるという馬鹿げたメリットしかないのです。

自作自演じゃないぞ（笑）

＞生島勘富さん、早速のお返事ありがとうございます。

＞SQLは
＞FROM → WHERE（JOIN） → GROUP BY → HAVING → SELECT → ORDER BY
＞の順で個別に実行されます。

勉強になります。ありがとうございます。

力がついたら、ビジネスロジック=SQL、UI=OO言語　でやってみようと思います！