上流の技術者はSQLを高いレベルで習得すべき
まともな議論になっています。炎上というのはコメントをつけてくれた方々に失礼かもしれませんが、何回も炎上してきたし、何回も同じことを書いてきたし、それどころか10年言い続けてるし……。
がしかし、この業界のお客様から、このようにご意見を頂戴した（わたしが猛烈に望んでいたコメントなんですけど自作自演じゃないからね）。
http://el.jibun.atmarkit.co.jp/g1sys/2009/06/vb6-8111.html#comment-24715757
そこで、以前からの蒸し返しですが、「上流の技術者はSQLを高いレベルで習得すべき」と改めて一度、声を大にして言いたい。
その前に余談ですが、VB6と.NET（とSQL）について。
どっかでコメントしましたが、VB6の利点は「ユーザ側のSEが理解できることが（現状では）多い」ことです。わたしが現時点でVB6を選ぶときは、ほぼこの理由です。
ユーザ側の社内SEにスキルチェンジを求めるのは酷です。ユーザ企業がコストをかけて社内SEにスキルチェンジさせても、そのコストを回収するのは開発会社より何倍も大変（というか不可能）ですから、社内SEがVB6に慣れているなら変えない方が良いのです。
で、ユーザの社内SEが「会社のコストでスキルチェンジしたい」と望んでいるときがあります（おそらく自身の将来を考えてか、新しい物好きかどちらかですが）。そのときは、社内SEの肩を持って「VB6はサポートが切れてますから、とてもお勧めできません」って言います。日和見と言われても（言われへんか？）、こちらもビジネスですし、本人が望んでいたらスキルチェンジのコストは案外低いから（そういう人はしっかり自習するし）OKとみなします。
いずれにしても、新しいかどうかは判断基準に入れる必要もないし、入れるべきではありません。
ところが、わたしはSQLに関しては、ユーザが望まなくてもかなりゴリ押しで入れます。これも好き嫌いでやってるのではなく、ユーザの社内SEが仕方なくメンテしているうちに覚えてもらえば大変な価値があるから、半ば無理やりに押し付けるわけです。理由は「どうしてもパフォーマンスが出ないから」ということにしますが、嘘ではないです。
ユーザの社内SEの仕事というのは、ちょっとした集計、ちょっとした切り口の違う帳票、というアドホックな要望に応えるというのが結構な割合であります。
これらの業務は、SQLを知っているか否かで劇的な違いが出ますから「イヤヨイヤヨもなんとか」で、社内SEを染めることもします。最初は滅茶苦茶嫌われますけど、1年、2年すると大概分かってもらえます。親の意見と冷酒とSQLは後で効くってやつです。
閑話休題。
コメントの話ですが、SQL Server6.5／Delphi1.0 で作られた5時間かかる月次処理をDelphi5で、極力SQLを使う方針で書き直すと、3分で終わるようになったとのことです。
バージョンから見て、1996年ぐらいに作ったものを2001年ぐらいに改修したぐらいのイメージでしょうか？ このコメントの内容ならば、自社で解決せずに作ったSIer（と呼びたくないレベルですが）に相談したら、おそらく「ハードのせいにして乗り切るパターンだな～」と思いながら拝読いたしました。
改修の時点で手に入るそれなりのハードにリプレースすれば1、2時間で終わる処理になったでしょう。その場合、顧客は本来は数分で終わる処理であることは知りようがないですから、5時間も掛かっていたものが1、2時間になれば、顧客の要件は満たされたことになるのです。
こんなもの（ハードで解決するなんて）分かっている人間から見れば詐欺みたいなものです（そもそも5時間もかかる時点で詐欺ですが）。
そんな詐欺師にならず、まっとうな上流技術者になるなら、最低でも
http://www.g1sys.co.jp/seminar090515.html
http://www.g1sys.co.jp/seminar090515_answer.html
これぐらいできなくてはいけません。異論反論は受け付けますが理由は以下で説明します。
わたしは技術にこだわっている様に見えるので、レベルの低い上流技術者に下に見られます。ホンマ「ふざけるなよ！」と言いたい。
いただいたコメントのシステムは「月次会社業績成績処理プログラム」というもので、経営会議資料を提供するものだそうです。（数日後ではなく）翌日の経営会議で必要な資料で、夜間バッチ（無人）を選択されず、徹夜で修正してリランしてでも絶対に翌日に利用する。
つまり、コメントをいただいた方の会社は、経営会議に最新の集計結果が必要な、数日のタイムラグが問題になるほど動きの早い業界だということが予想されます。
であれば、もしわたしが最初からコンサルとして入っていたら、「長くとも数分でできますから、締日に関係なく実行し、いつでもその時点のリアルな状況を把握できるようにしましょうか？」という提案になったでしょう。
つまり、仮締めともいえるし、シミュレーション機能ともいえます。コメントから分かる範囲での予想ですが、実現できれば経営判断に対するシステムの貢献度がまったく違うものになるでしょう。
逆にそのシステムを納めた上流技術者たちは、5時間もかかると初期に予想はしていなかったでしょうが、無人の夜間バッチを選択するか、入力締めの時間を決めて、それから管理者の監視の元でのバッチ処理を行うジョブフローを検討したことでしょう。
わたしがいたら、リアル処理でシミュレーションする機能をつくり、その機能を経営に活かすために他にどんな機能が必要か、といった内容の打ち合わせに持っていきたいと考えます。
さて、どちらが上流の仕事でしょう。
仮に、下流に5時間かかるモノしか作れない技術者しかいなければ、コメントの案件で「リアルな状況把握」は絵に描いた餅です。処理のレスポンスをある程度の精度で予想できて、製造方法を指示できて、それを経営にどう効率的に適用するか提案して、はじめて上流技術者としての職責を全うできるわけです。
わたしは、それがどれほど経営に貢献できるか、SIerとして価値のある仕事になるか分かっているので、顧客の前で身内を説得するしようとします。しかし、演習問題の答えを見ても「これは無理だ」って人が多いのに、最初の打ち合わせの席でわたしの考えを伝える方法は存在しません。そこでバッチの前提ができてしまったら、もう後では影響が大きすぎてひっくり返せなくなるのです。ですから、わたしは説得を試みるのではなく、他の技術者が何か言う前に、「リアルに状況が見れるようにできます！」と顧客に対して言質を渡そう（普通は取るものだ）とします。現状では、それしか方針を変える方法がないわけです。
そんなことしかできない自分が嫌で10年以上悩んでいます。「お前らちょっとはできるようになれよ！」ってなことを言っても、プライド高きコンサル様は「いまさら言語の講義を受ける」などありえないと思ってらっしゃいますし、根回しとかコミュニケーション能力とか、そういう次元で乗り越えられない（と思っている。批判は受けるし、解決方法があるなら教えて欲しい）。
その最初の打ち合わせで負けたり（多数決が正しいなら勝てっこないです）、参加していなければバッチ処理が前提とした打ち合わせであったり、設計であったりというところから参加することになるわけです。「ジョブフローを考えてください」って言われるのは、つまり左折で行けるルートを考えて作れということですな。
顧客に言われたものを、そのとおり整理するレベルが上流技術者じゃないでしょう。工数、レスポンスの問題ではなく、顧客が思っている以上の提案ができるかどうかが上流技術者として職務の根幹にかかわる問題じゃないですかね？
難しい処理、時間がかかる処理というのはシステム全体として数は多くないでしょう。しかし、顧客にとっては時間をかけてもやりたい、やらねばならない処理なのです。簡単な処理は誰がやっても差が出ませんから、難しく時間がかかる機能でコンサルが活躍しなければどこで活躍するのよ？
わたしが作った演習問題は、小さくて短時間でできて、汎用的なもので、ある程度の難易度で、という基準でコーディング能力を測るために作ったため、内容としては経営的な緊急性はないものになりました。コンサルへの影響は低いと思われる結果になっているかもしれません。しかしコンサルの職域を考えると、あの程度の演習問題すらできないとすると、確実にいただいたコメントのような範囲、つまりコンサルが本来的に活躍すべき内容で誤った判断をします。
結局、演習問題ぐらいできなければ、上流の技術者としての仕事はできてないわけです。
それでも、自分は成功してきたと思うコンサルはいるでしょう……。でもね、実際のシステム開発では、コンサルが思い描いたゴールが成功ラインとなるのです。
いただいたコメントの内容なら、ハードを変えて2時間以内って成功ラインを作ってそれを顧客に納得させればOKですね。
つまり、単純に成功ラインを下げてそれを成功としてきただけの話です。
繰り返します。演習問題ぐらいできなければ、上流の技術者として本来の仕事はできてないです。
まぁ、合意は取っているので誤ってないのですけれど、ベストソリューションは提供できないのです。わたしから言わせれば、それらは全部失敗プロジェクトです。
逆に、仮に顧客側から「シミュレーションしたい」と話が出たときに、顧客を納得させて断ってくるコンサルが「できる（優秀な）人」といわれ、御用聞きタイプは調子よく「できる前提」で話を進めてきます。御用聞きタイプが上流にいたら、結果、下流を地獄に突き落とすことになっているでしょう。
デスマーチに陥らせるのは御用聞きタイプの場合で、それよりマシといえなくはないけれどね……。
余談ですが、御用聞きタイプがデスマーチに陥らせたプロジェクトが今あれば、ご連絡いただければ助けてあげれるかもしれません。悪魔に魂を売ってもいいならご相談ください。テーブル設計を見た瞬間に「1から作り直すしかないですね、ごめんなさい」ってのも多いから、成功報酬で受けますよ。
当たり前ですが、上流の技術者がグランドデザインをするわけですから、最終結果が上流技術者の予想以下のものになることはあっても、それを超えるものにはなりません。もし、超えることを期待するなら、下流の技術者と立場を変わるべきでしょう。
成功のレベルを下げるパターンも、御用聞きタイプも、さすがに守秘義務があって実例は挙げれないけれど、実際は枚挙に暇がない（というか、同じプロジェクトに両方のパターンがほぼ入っていたり）。この業界に数年いたら、誰でも、どちらのパターンも必ず経験しているはずです。
そんな業界を何とか変えたいのですけれど、悲しいことに、現状ではコンサルを必要とするような案件にはわたしはお呼びじゃない。彼らが決めた成功ラインを超えることを言い出す奴は、お調子者の馬鹿タレの超危険人物ですからね。
嫌味ですけれど、彼らの能力をスケールアウトしてしまうと、どうしようもないのです。
そしてわたしとしても、そのレベルの自称コンサル様に「所詮、技術者で業務を分かってないとか」言われたりしたら……。10年以上もよ……もう怒りの導火線は擦り切れて3mmぐらいしか残ってないのですぐ爆発してしまう。
ユーザ企業様が見てくれたらいいのですけれど。業界では、弊社もわたしもゴミみたいな存在ですからね。彼らのような、馬鹿高くて仕事のできない連中を駆逐できるのはユーザ様しかないのです。
暇でもないけれど、とりあえず7月は暇になるかもしれないので（苦笑）、今のコンサルが怪しいと思ったら、セカンドオピニオンとしてでもご依頼いただければ幸いです。お問い合わせはメールで。 info@g1sys.co.jp
繰り返しですけれど、成功ラインを既得権を持った上流の技術者が決めているのですから、情けないけれどユーザ様が協力してくれないとわたしが勝てることはありません。たぶんユーザ様とわたしは利害が一致しているはずですから、ご協力いただければと思います。
そんなわたしを使うようなコストを掛けなくても、コンサルに演習問題みせて、開発方針を聞けばわかります。「何でもできます」という御用聞きタイプには、これが××時間でできるのに、なぜその見積りなのか？ ってのも効果的でしょう。
コンサルや上流SEにとって重要なのはSQLができるかどうかではありません。SQLを選ぶかループを選ぶかの判断、つまりSQLでできると判断するかどうかです。「何でもできます」という御用聞きタイプでなければ、コンサルは演習問題ぐらい見た瞬間（聞いた瞬間）に判断しています。
下流にできる人がいなかったら指示できるか、自分で作れないと意味がないですが、できると判断する人なら、時間をかければ自分でできるでしょう。10分でできる人もいるかもしれませんし、2時間かかるかもしれませんし、1日あればできる人がいるかもしれません。そのぐらいは提案内容でミスすることから比べれば、システム全体では誤差の範囲ですから、できるかどうか判断できればよいのです。
富士山の山頂から降りるとき、山頂ではほんの少しの方向の違いであっても、結果は静岡に出るか、山梨に出るかぐらい大きく変わります。上流の技術者とは、山頂で降りる方向を示す立場ですから、演習問題ぐらいは見た瞬間（は言いすぎですが、打ち合わせしながら）に判断できなければ話にならないのです。というか無意識にした判断で、とんでもない方向を指してしまう。
工数など、下流に対する指示だけではなく、運用設計やシステムの概要設計に非常に大きな問題が出て、5年、10年変えれない障害を残すことになります。
成功ラインはその時点では全力を尽くしたベストだった、ってな言い訳もね……。SQLは10年前の技術で、今も使われている息の長い技術です。いい加減、知らないできないで済ますのはやめにしましょうよ。
◇ ◇ ◇ ◇
7月は暇になる可能性が高いので、準備期間が短すぎですがセミナーをやります。
大阪じゃ集まりそうもないから、平日2日間（16、17日）、土日2日間（18、19日）に東京で。
もちろん有料です。セミナールーム使用料、わたしの移動と滞在費などを含めると10名ぐらい確保できないとペイしないので、最少催行人員を超えることはないかな。
1回目だけは安くします（次からはコンサル様がプライドを維持できるぐらいの価格設定にするけど）ので、ご興味のある方は info@g1sys.co.jp まで。
対象者はコンサルになるのよね～。ここまでコケにして……。本当に商売が下手くそやと自分でも思いますが、お客様にはやさしく解説しますので、ぜひよろしくお願いいたします。
◇ ◇ ◇ ◇
最近、訳あってちょっと時間ができてしまった。高い頻度で書いているのは、不況で暇だからと思っていただいて差し障りないです。不況はつらい。「提案中の、あの案件やこの案件が、もし取れなかったらどうしましょ」って不安があって、荒れ気味の話ばっかりですみません。
友ぞうさんのところで「コラムで愚痴を……」というようなご批判があり、厳しいなと……。わたしの場合、章立てしてないときは、あらすじすら考えず、イライラをぶつけているようなものです。もちろん、ずーっと考えていることなのでブレることはないと思うが、行ったり来たりでクドくなっているなと思う。
すみません。
結構コメントにも時間を使っています。ギャランティはゼロですから、多少は会社の宣伝になってくれないと困るのですけれど……。マイナス効果の方が強かったりして（苦笑）。
コメント
saki1208
saki1208です。
ウチでは、例えバッチ処理であっても、一回の実行に5時間もかかる
ようでは納品物として認められないでしょう。常識的に考えて、異常
としか言いようがないです。
もちろん、PCのスペックやデータ量にもよりますから一概には言えな
いのですが、それにしても異常です。
作る側として、おかしいと思う感覚がないのでしょうか?
確かにこのようなSIerが増えると、業界全体が信用されなくなり、悲
しいことになりますね。
saki1208さん、こんばんは。
まぁ、SQLを覚えたらというのは、パフォーマンスだけではないのですが、
なかなか、説明するのは難しいです。
成功ラインを決めるコンサルに、その違いが分からないというのは話に
ならないのですけどね…。
2時間が2秒ってのもありますから、とてつもなく下手糞も存在します
けれど、普通の技術者でも、私の経験でSQLにロジックを寄せたら、
大体20倍のパフォーマンスの差が出ます。
なんと言いますか5時間はありえないでしょうけれど、オンライン処理を
選べるのは数十秒まででしょう。
と考えると、20分ぐらいのものは大体、SQLに直せば60秒ぐらいになり
ます。1990年代なら果てしなく下手糞もいたし、ハードもきつかった
ので、もっとひどい差がついたのですが、この差は現在でも大きいと
思います。
成功といわれているプロジェクトでも、突っ込みどころは山のように
ありますが、なかなか突っ込むチャンスはありません。
saki1208
saki1208です。
まあ、確かにパフォーマンスの話が一番解りやすいので、いつもその話が
多くなりがちですね。
本当の良さは、もっと別のところに…
# 生島さんはいつも声を大にして仰ってますけど。
ビジネスロジックの実装とUIの切り離しがきちんとできれば、処理の実装
にUIが影響されることも少なくなりますし、内部ロジックの変更に今ほど
神経を使う必要もなくなるのではないかと…
私は10年ほど前から「どうすれば?」に取り組んでいるつもりなのですが、
周りからは中々理解を得られません。逆にUIにビジネスロジックが鏤めら
れている方が解りやすいそうです。
# そのせいでいつも苦労するにも関わらずです。
業務システムの一般的なチェックロジックなんてどんなシステムでも殆ど
同じだし、特殊なパターンだけ外部アセンブリとかにしてリフレクション
使って呼び出すとかで良い気がするのですけど、なぜか一から作りたがる
んですよねぇ。
# 多分、人月でしか計算できないからでしょうけど。
インドリ
私はSQLに限らず情報処理技術全般を学ぶべきだと考えております。
プログラム言語としては・・・
命令型・関数型・論理型・問い合わせ型・スクリプト言語の5系統を2個づつぐらいは修得して欲しいです。
そうしないと、オブジェクト指向分析／設計なんて出来ないです。
実装を意識しないと無知でもいいは別物です。
オブジェクト指向分析／設計の際に、明後日の方向を向いていれば駄目なのです。
最終的には電子計算機が処理するのですから、その特性を踏まえた分析／設計をしないと駄目なのは当然の事です。
他にもOS知識・ネットワーク知識・データベース知識・セキュリティ知識は必須です。
そもそも上流／下流なんて分類馬鹿げています。
片方だけやったら駄目なのは当たり前です。
片方の車輪でシステム開発という名の車は走れません！
四の五の言わずに両方やればいいのです。
そうすれば、頭の中で最終結果がシュミレーション出来るようになります。
工数を減らそうとする私が馬鹿なのかとも思わなくはないけれど、
上流と下流が同じ会社というのはほとんどないわけで、上流なら
全体工数を下げることが、もっとも自分の利益にかなっているはず。
上流は人月関係ないはずなんですけどね。
彼らの能力不足で自分たちの職域で問題を起こしているのですが、
それを正すのではなく、覆い隠すことができるのが上流の仕事って
ことなんですね。
やっぱり、上流、下流ではなく、内部、外部と分けるべきでしょうね。
temp
ちょくちょく拝見させていただいているのですが、
生島さんがおっしゃっている立場や気持ちについては
よく理解できます。
ただ、細かいことになって申し訳ありませんが
例に出されているＳＱＬサンプルについて疑問があります。
消費税配賦対象になるランク境界の明細に同一金額が
２行以上ある場合にこの方法では余分に加算されてしまわないでしょうか。
（例えば、消費税丸め方法が切り捨て・納品書単位で
明細金額が90円・90円・40円の３明細しかないような場合）
前々から気になっていたのですが、頻繁にリンクされているので
今頃になってからですが質問させていただきます。
私の理解不足であれば申し訳ありません。
oumi
今回は、長い記事で「えらい気合い入ってるな・・」。ほぼ頷きながら、でも少し違うなぁ・・なんて思いながら読ませていただきました。
少し違うと思った中から、特に「ちょっと違うけどかなり違うかもしれない」と感じた部分についてコメントさせていただきます。
----------
コンサルや上流SEにとって重要なのはSQLができるかどうかではありません。SQLを選ぶかループを選ぶかの判断、つまりSQLでできると判断するかどうかです。
----------
この部分です。これは言いかえると、特定の要素技術で可能かどうかっていう事になりはしませんか。このような考え方では、少々危険かなと思っています。システム開発において、早い段階で特定のアーキテクチャを決定してしまうのは危険だと考えているからです。
また、SQLかループかは、専用言語か汎用言語かという対立ではありませんか。これもまた、実装段階に近い時点では決める事自体が重要ですが、超上流～上流にかけては、いささか早いかなという気がします。（もちろん、上流には幅も色もありますし、シチュエーションにより答えを出すスピード感などが必要な場合があるでしょう。ですので、ここでは規模感やシチュエーションなどは無視した話をしているつもりです。）
ですので、
コンサルや上流SEにとって重要なのはSQLができるかどうかではありません。今選択しようとしたアーキテクチャが最良か、他にも有効な手段はないのか、何故それで満足なのか、といった自問自答を短時間で数多くこなすことです。そして、その時に、専用言語であるSQLを始めとしたRDBMSの持つアーキテクチャも必ず選択肢の上位に置く事です。（「そして、」以降はサービス）
といいたいなと思います。ちょっと違うだけに見えるけど、かなり違うと思います。
生SQLにするか、アクセス用のプロバイダは何使うか、パラメタライズドクエリーにするか、プロシージャにするか、LINQの可能性は、EDMはどうだ、アクセス用のプロキシクラスを実装してはどうか？バッファは大丈夫か、ログはどれくらいでるか、などなど、いくつもの可能性を瞬時に考え、完全な数値は出なくとも、見極めができる程度の脳内整理ができると良いと思います。
とはいっても、そのダメダメコンサルが立ちはだかるのをぶち壊すために、あえてのタイミングでSQLでさ！？なんて言うのは勇気ある・・・・私は、裏からチマチマ遠まわしに政治的な方法で何かって考えるけど（性格に問題あるのでｗ）
もっとも、そもそも的な話で、SQLを選択肢の第一に置かない（おけない）コンサルやアーキテクトが設計したDatabaseでSQLがまともに使えるか、なんていう話もあるかな・・・
なにこのINDEXの沢山張れるISAMの集合！
何この無差別第３正規化テロ！
とか・・・
追記.
最近、物書きばかりしているので、リフレッシュするために、役立つブログのひとつになりつつあります（笑）
> コンサルや上流SEにとって重要なのはSQLができるかどうかではありません。
> 今選択しようとしたアーキテクチャが最良か、他にも有効な手段はないのか、
> 何故それで満足なのか、といった自問自答を短時間で数多くこなすことです。
> そして、その時に、専用言語であるSQLを始めとしたRDBMSの持つアーキテク
> チャも必ず選択肢の上位に置く事です。（「そして、」以降はサービス）
おっしゃるとおりで上位に置くことです。
余りごちゃごちゃ書くと、ボケちゃいますので絞ってますが、
必要であればCOBOLも候補に入れるぐらいで考えねばなりません。
もちろん、余りにボカすとややこしくなるので、はしょっていて
すみません。
tempさん、始めまして。
テストしてないのバレバレですね。（物理名が合ったDBを作るのが面倒で……）
勘違いしてました。
ORDER BY の最後に主キーを追加しないといけませんね。
ご指摘いただき、ありがとうございました。
oumiさん、追加です。
もちろん、まぁ、根回しというか、政治力を利用した寝技とかもするのですけどね、「これは後からはひっくり返せない」って判断した瞬間に顧客に言質を渡しにいきます。
そういうセコイ技を使わなくてもいい、信頼しあえるメンバーだけで仕事ができたら良いのですけれど、現実問題として、そこまでのメンバーがそろうことは余りないので……。
それぞれに専門性が高くて立派なんですけどね……。
全体的に、マネージメントに寄りすぎというか、技術を軽視しすぎだと思います。
tk
こんにちは、tkと申します。
生島さんのコラムは、非常に勉強になります。いつも興味深く読ませて頂いております。
ところで、
＞大阪じゃ集まりそうもないから、平日2日間（16、17日）、土日2日間（18、19日）に東京で
ま、マジですか・・・。
と言うのも、私は現在大阪市内で働いております。
前回のセミナーにも参加しようか迷ったのですが、その当時はまだ生島さんについてよく存じ上げておらず、見送りました。
それからは、暇があればコラムだけでなく、コメントもかなりの部分を拝読致しました。生島さんの考え方には、共感できる部分が非常に多く、「あなたは俺か！？」と、時々思ってしまうぐらいです。
そんなこんなで、次のセミナーには絶対参加する！！と常々考えていたところの東京開催のお知らせを聞いて、こんな事なら前回参加しとけば良かったと少し後悔しております。
しかし、善く善く考えてみると、７月ならば連続休暇（夏休み）を取得できます。ですので、都合が合えば参加させて頂きたいと思います！
それでは。
がると申します。
「高いレベルのSQL」というものの定義に興味を持ちました。
個人的には…正直なところ。DBMS毎の差異(或いは方言)やスケールアウト、ビジネスロジックの散逸などから、「SQL一発でゴンと出す」という状況に、必ずしも是と言い切れないものがある、と感じております。
無論様々な現場環境などあるかと思いますので。生島勘富さんのお考えなどを窺う事が出来れば、と思い書かせていただきました。
お時間のある時にでもご見解など窺えれば幸いです。
がるさん、はじめまして。
> 正直なところ。DBMS毎の差異(或いは方言)やスケールアウト、
> ビジネスロジックの散逸などから、「SQL一発でゴンと出す」
> という状況に、必ずしも是と言い切れないものがある、と感じております。
プロジェクトは個別の問題があります。
が、個人的な経験でしかないですけれど、DBMSが変わることと、
プログラミング言語が変わることの割合は2:8ぐらいの割合で、
DBMSが変わることの方が少ないです。
ビジネスロジックはDBに入れた方が散逸しないと思いますけどね……。
必ずしも是とは言えませんが、かなり多くの場合、是です。
多い少ないの問題でであれば、DBを理解していることで解決
できることは多く、理解してないためにとんでもないことが
起きることが非常に多いです。
割合の問題じゃないですかね。
VB6と.NETでたくさんのご意見をいただきましたけれど、
そんなものは話にならないぐらいの差になりますよ。
がるさん、すみません、追加です。
弊社の基準で、
SQLServerのストアドプロシージャで目一杯組んだ
ものをOracleへリプレース
ASP.Netで組んだものを、Javaへリプレース。
おそらく、前者の方が安くなります。
可能性としても、DBの移行の方が少ないです。
どうしてもマルチDBで、開発せねばならないパッケージも
存在しますけれどね……。
特殊な事例だと思いますよ。
インドリ
SQLといえば、最近はXQueryとかのXML関連のSQLについては生島さんはどう思われますか？
また、オブジェクト指向データベースとネイティブXMLデータベースについてはどう思われますか？
そして、DBMS製品の選定方法はいかにお考えでしょうか？
プロジェクトに於いてかなり重要な事だと思いますので、データベースの選定基準について教えていただきたいです。
tk
おはようございます、tkです。
＞もしかすると、某プロジェクト向けに（社内じゃないけど）やるときに参加してもらうパターンもありかな……。
おおお！是非、期待しております。
今からメールお送りします。
tom
temp改めtomです。
例のSQLに関しては、order by の問題ではありません。
DENSE_RANK関数に関しての勘違いではないでしょうか。
[金額]...[DENSE_RANK()]...[RANK()]
-----------------------------------
...90..........1............1
...90..........1............1
...40..........2............3
なので、どちらの場合でも２行とも加算されてしまいます。
DENSE_RANK()使用時は、加算対象内に同一金額行が１つでもあると
よけいに加算されると思います。
RANK()使用時は、加算対象の最終ランクが複数ある場合に
よけいに加算されます。
私の勘違いでしょうか？
(oracle10gで解答のＳＱＬ文を実行してみましたが
やはり余計に加算されました。）
プロを自称されている方がずっと間違ったＳＱＬ文を
提示しているのが気になっていて我慢できなくなり
投稿させていただきました。
tomさん、はじめまして。
ご指摘ありがとうございます。
お手間掛けさせて申し訳ございません。
勘違いですね。
ORDER BY の後ろに主キーを入れていただければ問題ないはずですが、
ROW_NUMBER()を使うべきところでした。
後ほど修正しておきます。
XMLですか。
外部接続があって相手も採用していれば便利ですけれど、今のところ私の周りではデメリットの方が大きいので採用することはないですね。
転送量が増えて、タグが小さくなるように変更したりと騒いでいるプロジェクトは見たことがありますけれど、それでも苦労してたな。
オブジェクト指向データベースとか、余りメリットも感じないし、新しいから飛びつくという考え方はないのです。それが顧客に対して十分なメリットとなり得るかどうかと考えると、現状ではならない。
VB6と.NETの話と同じ基準で検討します。
（どちらでも良いときは、ちょっと好みを入れさせてもらうけど）
matsin
次回セミナーは東京ですと・・・。
やられましたｗ
大阪で土日なら参加できたのですが。。
matsinさん
コメントありがとうございます。
ジーワンシステムの生島です。
大阪はこっそり弊社の小汚い事務所で3～4人ぐらいでやります。
今回はSQLServerになるのですけれど、
7月4日、7月5日
7月4日、7月11日
7月11日、7月12日
のいずれかのパターンで考えております。
よろしければ、ご参加ください。
がるです。ご返信有難うございます。
拝見していて、色々と背景の違いが見えて興味深かったように思います。
私の場合、いわゆるLAMP系を中心にした、Web周りが多いのですが。
私の周囲に限定した場合。DBMSが変更になる可能性はあり得ますし、またそのために「DBMS変更に配慮しているかしていないか」は、後々、色々と重要なポイントになる事もまた少なくないです。
またWeb系は「比較的シンプルであることが多いSQLが大量に流れる」事が多いため。
無論SQLのチューニングも大切なのですが、それ以上に「DBサーバ側に負荷をかけない」「スケールアウトが容易であるようにしておく」などの状況が欲しい事がままあります。
ビジネスロジックについては…出来れば「プログラム内でそろっている」ほうが、個人的には有難いと感じてしまうほうです。
＞＞
弊社の基準で、
SQLServerのストアドプロシージャで目一杯組んだ
ものをOracleへリプレース
ASP.Netで組んだものを、Javaへリプレース。
＜＜
については。私の場合
・シンプルなSQLのみにする代わりに、ほぼノーコストでDBMSを変更
という選択肢を作っている感じですかね。
このあたり、おそらくWeb系と、生島様がなさっている(とかってに予想しているのですが)業務系、とで。色々と性質上の違いがあるのかもしれません。
あと、よろしければ二つほど、ご意見を窺いたいのですが。
一つ目が。
これはいわゆる「オラクル屋さん」数名にヒアリングして…少々驚いたのですが。「数学の集合論としてのリレーショナルデータベース」というのは、あまり学ばないものなのでしょうか？
無論最終的には「実装への意識」というのは不可避だとは思うのですが、そうはいっても「基礎概論」を全く学んでいないという返答が連続で帰ってきてしまうと、少々、門外漢としては驚くものがありまして。
二つ目が…上述に紐付く話にはなるのですが。
SQLが「関係モデル」から逸脱している、という話があるかと思うのですが、そのあたりについて、実際に現場でガリガリとSQLを書いてらっしゃる方々はどんな風にとらえてらっしゃるのでしょうか？
全体的に散文になってしまい恐縮ですが。
お時間がある時にでもご意見をいただければと思います。
がるさん、ども。
WEB系は単純なことも多いのかもしれませんが、
> またWeb系は「比較的シンプルであることが多いSQLが大量に流れる」
> 事が多いため。
> 無論SQLのチューニングも大切なのですが、それ以上に「DBサーバ側に
> 負荷をかけない」「スケールアウトが容易であるようにしておく」
> などの状況が欲しい事がままあります。
逆ですね。
SQLを大量に流した方が圧倒的にDBの負荷は高まります。
複雑なSQLを書いたときのピークの高さが気になっているだけでしょう。処理全体を見て、両方の処理で、たとえばCPUの使用率と時間のグラフを書いてみてください。そのときの面積の大きさがDBサーバに掛かる負荷です。
もちろん、下手糞なSQLを書いたら駄目ですけどね。
http://www.g1sys.co.jp/column/_sql_2006_3_1_2.html
最終的な結果はSQLで処理しても母言語で処理しても変わらないということはDBがトータルで行う処理は変わらないのです。
で、SQLが大量に発行されるか1回かの違いが出ます。
DBサーバはSQLを受け取るたびに、文法は正しいか、すべてのテーブル・カラムは存在しているか、インデックスを使うべきかどうか、といった分析を行うのですけれど、それが大量に繰り返されたら大変なコストになります。
また、データだけでなく、SQL文も大量に通信されるのですから、トータルで考えると、何倍も重い処理になってしまいます。
ただ、MySQLは内部構造が単純な分速いけれど、RDBMSと言うには余りに非力でできないことが多い。MySQLを視野に入れるときは、かなり制約がありますね。
ブログシステムのようにRDBMSというよりも、ストレージとしての側面が強いシステムでは、そもそもの処理が単純ですから、母言語でやってもよいと思いますが、ECサイトや業務システムになるとSQLで処理した方がよいでしょう。
集合理論は分かっているつもりですが、特に専門的に勉強したわけではありません。
関係理論に合っているかどうかは、顧客にはまったく関係ないことなので、気にしたことがありません。
私は学者でも、研究者でもないので、実際に起きている問題をどう解決するか、いかに工数を抑えてよいものを作るかということしか、残念ながら興味がありません。
インドリ
>SQLが「関係モデル」から逸脱している、という話があるかと思うのですが、そのあたりについて、実際に現場でガリガリとSQLを書いてらっしゃる方々はどんな風にとらえてらっしゃるのでしょうか？
これ私も答えていいのかな？
関係モデルから逸脱しているのはその通りです。
長らくSQLは集合指向的（あくまで的）な言語だといわれてきました。
しかし、SQL1999を経て大分集合指向な機能が増え、SQL標準規格の重要人物ジム・メルトン氏もSQLは集合指向言語だと明言しています。
ただ、プログラミング言語の機能を付加して欲しいという要望が多数寄せられ、その要望に対応する事により関係モデル以上になっています。
具体的には、手続き型言語の制御構文、オブジェクト指向要素の付加、XML対応（SQL2003）など付加されています。
ですので、SQLは結構関係モデルから逸脱しています。
これは実務を意識しての事だそうです。
インドリ
書き忘れていたので追記します。
ストアドプロシージャをプログラミングする事や、複雑なデータが増えるであろう事を考慮するとこのSQL標準規格の方針は正しいと思います。
私たちは技術者なので学術的よりも実務製を重視しますのでこれでいいのです。
「いわゆるLAMP系を中心」にされている方達は、ブラウザ（閲覧ソフト）に入力機能を持たせる愚挙は何とも思ってないようですけどね……。
それは、SQLと関係モデルなんて比じゃない。小学生でも分かるぐらい理論的におかしい。
HTMLだって本来はマークアップ言語ですしね。「スクリプトを組み込めば便利」と考えるか、「本来の意味から逸脱する」って反対するかと考えればいい。
本来の意味から逸脱しても流行るというのは必然性があるわけです。
で、流行りすぎると、逸脱した目的すら失われてしまうこともある。
SQLでいうと、ストアドプロシージャで外部プログラムを叩いたり……。
WEB系でいうと、外部公開しない基幹システムをWEBシステムで構築したり……。
この辺のガイドラインも、結局は「ユーザにどれだけの便益があるか」という視点でないと答えは出ません。
ルールや法律は守らねばなりませんが、ガイドラインは、あくまでもガイドラインで、絶対に守らなければならないものではありません。
顧客に合わせて是々非々で考えればよいわけです。
で、なにを訴えているかというと、プロとして顧客の立場に立って考えて答えを出すには、特定のスキルが欠けているのは大変な問題があるわけで、SQLのような古くて今も広範に使われているスキルが足りないというのは、とんでもないことだと言っているだけです。
十分なスキルを持っている人が、あえてSQLを選ばないというのは、当然起こりうる話で、それを間違っているなどとは言ったことがないです。
たとえば、私自身、SQLはまったく関係ないプロジェクトをいくつも企画していますし。
しかし、現状では、スキルが足りないために「是々非々になっていない！」、厳しく言えば「君らに判断するだけのスキルはない！」と主張しているだけで、「とにかく、自分ができないから非！」って奴を駆逐するために私は活動しているわけです。
がるです。
たびたびのご返信、有難うございます。
以下、散文かつ雑感で大変に恐縮ですが。
> > 無論SQLのチューニングも大切なのですが、それ以上に「DBサーバ側に
> > 負荷をかけない」「スケールアウトが容易であるようにしておく」
> > などの状況が欲しい事がままあります。
>
> 逆ですね。
> SQLを大量に流した方が圧倒的にDBの負荷は高まります。
同一の意味を持つSQLを「１本できれいに作った」時と「複数本にしたとき」であれば、「DBの負荷が高くなる」というのは確かにそうだろうと思います。
ただ…私は、上述を「スケールアウト」の観点から…中間のいわゆる「処理分散装置」の事も含めて考えた時に、ひとつの方法として「テーブル単位で別々のDBサーバに格納する」という事をやる時がありまして(いくつか制限はありますが、非常に安いコストで可能な方法のひとつです)。
そうすると「全体としてのDBサーバ群の負荷」は上昇するのですが、「ここのDBサーバの負荷」は、ある程度分散させる事ができるので(で、効率としては、ロードバランシングよりコストパフォーマンスがでる事も多かったので)。
そういった状況が念頭にありました。
…もっともこのあたりをもう少しまじめに捉えるのであれば、いわゆる「分散データベース」というあたりにたどり着くのだろうと思うのですが。
学術周りについては…
> 集合理論は分かっているつもりですが、特に専門的に勉強したわけではありません。
> 関係理論に合っているかどうかは、顧客にはまったく関係ないことなので、気にしたことがありません。
>
> 私は学者でも、研究者でもないので、実際に起きている問題をどう解決するか、いかに工数を抑えてよいものを作るかということしか、残念ながら興味がありません。
> 私たちは技術者なので学術的よりも実務製を重視しますのでこれでいいのです。
理解いたしました。
私は(…まぁ私が出来ているかと言えば明確に「否」であり、だからこそ勉強が欠かせないと思っているのですが)、いわゆる「学問としての研究であるとか考察であるとか」の中にもなにがしか、実務に有益なものが多々あるであろうと考えているので。…まぁ非常に欲張りな発想なのだろうと思います(苦笑
で、その「欲張りな発想」から考えると、学術を「学んでいない」のが、なにやらもったいないような気がしてしまったので、質問をさせていただいた次第です。
> 「いわゆるLAMP系を中心」にされている方達は、ブラウザ（閲覧ソフト）に入力機能を持たせる愚挙は何とも思ってないようですけどね……。
このあたりは…そうですねご指摘いただいた今を含めて、あまり奇異に感じていないです。
まぁそも「HTTPで認証(authorizationのほうです)をする」事自体が奇異ではあるのですが(苦笑
> で、なにを訴えているかというと、プロとして顧客の立場に立って考えて答えを出すには、特定のスキルが欠けているのは大変な問題があるわけで、SQLのような古くて今も広範に使われているスキルが足りないというのは、とんでもないことだと言っているだけです。
これについては全面的に同意です。
SQLに限らず、だとは思うのですが。様々な要求があるなかで、如何に自らのスキルを深く広くするか、というのは必須なのだろうと思います。
ご丁寧な返信、有難うございました。
ryo
はじめまして、ryoと申します。
生島さんのブログをみるかぎり、コンサルタントと何かあったようですが、
やり取りを具体的に書いて頂いた方が共感（反論、炎上）を得られるのではないでしょうか？
炎上を期待しているようなので疑問に思ったことを質問してみます。
・SQLについて
>まっとうな上流技術者なら・・（中略）・・これぐらいできなくてはいけません。
と仰って掲載した回答ですが、URLを見る限り、1ヶ月以上も間違ったSQLを掲載していたことになります。
この辺りについては、どのようにお考えでしょうか？
OLAP関数についての知識がない人には難しいかと思われますが、DENSE_RANK()とROW_NUMBER()の選択ミスって、間違いとしては結構レベルが低いと思うのですが、いかがでしょうか？
ご自身が正解を出せない問題で、他者のレベルを判定するのはいささか無理があるかと感じます。
・問題設定について
この問題は消費税の割賦を行うものですが、消費税の割賦の処理は、請求書作成時に行うべきではないでしょうか？
請求書作成時には消費税の割賦は行われなければならず、経理システム用のデータ作成時に割賦を行うのは設計上疑問があるのですが、いががでしょうか？
請求書作成時にも計算して、経理システム用データ作成時にも割賦を行えばよいという設計は疑問を持ちます。
たとえば、数千万行の明細レコードに回答にあるSQLを適用するのはパフォーマンスが維持されるかどうか、躊躇しますが請求書作成時に割賦処理を済ませておけばそのような問題を考える必要がありません。
私の認識が不足しているところがあればご指摘頂ければと思います。
がるさん、ども。
スケールアウトについては次に書きましたけれど、ブログシステムなどRDBMSとしての機能というよりもストレージとしての機能が要求されるときは、お手製のクラスタリングを組むでしょう。
これは否定しませんよ。
しかし、ユーザ管理の部分を分けてしまうのは良くないと思います。
で、私が携わっているのは、ユーザ部分だけでも分けざるを得ないほどの規模だったりします。
Postgre Forest は何度も検討したけれど、その規模になればライセンス費などは誤差の範囲になるので、Oracle RAC になってしまいます。
SQLができる人が分けようとしようとするのと、SQLができない人が分けようとするのは根本的に違うはずです。
実際に違います。
ここを問題視しているのですけれど。
ryoさん、はじめまして。
検証いただき、ありがとうございます。
申し訳ございませんm(__)m。
１ヵ月ではなくって、いきさつはこの辺に書いたとおりで、
http://el.jibun.atmarkit.co.jp/g1sys/2009/03/sql-d43a.html
http://el.jibun.atmarkit.co.jp/g1sys/2009/03/sql-d141.html
のをそのまま使っています。
4、5ヶ月かな（笑）
守秘義務があって、フィクションにしないといけないので、架空のシステムを考えて、ありそうな要望を考えて、答えが難しそうで……、って記事を書いてみました。しばらくして、じゃあ答えを書いてみるかと、本当に30分で書けるかは検証しました（笑）
私の見積りは、過去の記事にあるとおり、
実装：30分
チューニング：1時間
テスト：1時間
資料作成：1時間
ぐらいでしたけれど、
実際、実テーブルがあってObject Browserなどのツールで書いたら2時間あったら全部終わるなと思いましたけどね。
今回は、DB作って、ダミーデータ作ってテストするほど、暇でなかったので、机上デバッグしかしてなかったのね。それで、答えを書きながら、消費税が計算済みじゃないってあり得ない……とか、1発でやるつもりの問題を考えてたけれど、3発(2発)にした方が効率いいなと。
まぁ、その辺の試行錯誤は必要ってことです。
フィクションじゃなく、現場であれば、1発と3発(2発)を見誤ったり、消費税が計算済みじゃないなんて設計はあり得ないのですけど、関数の間違いなんて、わたしは茶飯ごとで（それじゃ駄目ですけどね）、上流はイメージを考えるのが仕事で、細かいことは実装・テストで潰してよってことで……。
自分がやることだから、バグがない訳ないと思っていたけれど、遠大な釣りかどうかは（笑）釣りじゃないですよ。
申し訳ございませんでした。
余談ですが、記事にも書いたけれど、問題のネタなら、私はSQLでやらないと思います。
理由は、緊急性のないバッチ処理になるから。
要件から予想すると、遅くてもいいのですよ。
こんな細かいことを要求するシステムはそれなりの規模で、数人日は誤差ですから、私もまずゴネないと思います。
ってな条件で考えるようになれって話です。
リアルに書いているつもりなのですけれど、生の情報を書くことはさすがにできません。
通りすがり
久しぶりに覗いてみたら・・・
ご自分でも書かれてますが、その上で、炎上呼ばわりは失礼ですね。
純粋に質問させて頂いていただけなんですが、はぐらかしておきながら炎上呼ばわりとは。
特に怒りは覚えませんが、がっかりですね。
ところで今回言わんとされていることは、乱暴にまとめると
・上流の人間にも技術力が必要
・なぜならば、適切な「アタリ」を付ける必要があるから
・その中でも、SQLはとても大事だから覚えろ
ということであってますか？
誤読でしたらご指摘頂きたく存じます。
(以下正しいと言う認識で)
私の場合、追加要件でついた枝葉のせいでブレることもありえますから、「まぁ行けるな」「ちょっと無理かな、難しいかな」程度にしか掘り下げないです。
で、上記まとめが正しいのであれば特に異論は無いのですが、そうじゃない世界があるのですか？
いや、ま、確かに某成果主義崩壊な会社あたりでそういう世界があったような気もしますが、そうじゃない世界もいっぱいあるでしょうに。
ダメな会社なんて、放っておけば潰...
余計なお世話ですが、喧嘩なんて時間の無駄で、迂回した方が早いんじゃないかなあと。
ryo
生島さん
ご返信ありがとうございます。ちょっと長めになりましたがコメントします。
まぁ、プチ炎上ってことでご勘弁を。
・SQLについて
例として挙げられた問題ですが、現実的でないし、半日で出来ると言っていたものにバグがあり、更に
>余談ですが、記事にも書いたけれど、問題のネタなら、私はSQLでやらないと思います。
とまで言っています。で質問しますが、問題のSQLは上流の技術者は習得する必要があるのでしょうか？
・工数について
そもそも、問題を作成している方が、30分で答えを出したと言われても説得力がありません。
また、
>テスト：1時間
といわれていますが、
>今回は、DB作って、ダミーデータ作ってテストするほど、暇でなかったので、机上デバッグしかしてなかったのね。
ともいわれています。結局のところテストに必要な工数はいかほどでしょうか？
実際の見積もりでは、きちんと動くものを作成するのに必要な工数を見積もります。のでそのように見積る必要があるかと思いますが？
ちなみに、
http://el.jibun.atmarkit.co.jp/g1sys/2009/03/sql-d43a.html
では半日より長ければダメなようなことが書いてありますが、実際には半日以上掛かるということになるのではないでしょうか？
・結局のところ、何を主張されたいのでしょうか？
http://el.jibun.atmarkit.co.jp/g1sys/2009/03/sql-d43a.html
の記事を拝見しましたが、結局何がおっしゃりたいのでしょうか？
(1)2日で出来るものに2ヶ月掛けるのはおかしい
(2)SQL一発で出来ることにループを使うのはダメ
(3)コンサルが間に入って変に工程を切られるのがウザイ
(4)コンサルがSQLを覚えれば上記問題は解決される
ということでしょうか？ 今ひとつ生島さんのストレスの要因が理解できません。
私も技術者で、(1)～(3)のことを感じることはありますが、それで(4)とするには、論理の飛躍があるかと思います。
上記記事の
>リプレースなのですが、元は2万以上のステップで数時間掛かる重い処理だったらしい。ところが、わたしは数回の打ち合わせで、上のパターンでいくつかのストアドファンクションに分割されたところまで脳内にできています。非常に複雑なのでテストに相当時間が必要ですけれど、実装自体は2日あればできるのじゃないかな。
これ、本当に元のコードと互換性のあるものを2日できるとおしゃったのでしょうか？
元のコードって長年の改修が積み重なり2万以上のステップ数になったと想像できます。
その仕様を数回の打ち合わせで顧客なりコンサルタントが生島さんに伝えきれるとお考えでしょうか？
ドキュメントにない仕様が2万ステップの中にちりばめられているかと思いますがその確認はされた上での工数見積もりでしょうか？
また、実装に2日とありますがテストには何日かかるのでしょうか？
確かに為替差損益の仕分けでなぜ2万とも思えなくないですが、実際に2万ステップのコードがあれば慎重になるのも納得します。私がコンサルの立場でも「設計書を書いて仕様を明確にして欲しい」とお願いするところです。これは無理な相談なのでしょうか？
実装自体は任せてもよいかとも思いますが、プログラムの性質上改修も多いかと思われます。その場合、特定のエンジニアしかわからないトリッキーなSQLを書かれるよりベタに作成してくれというもの無理な相談ではないかと思いますが、いかがでしょうか？
SQLの知識云々ではなくプロジェクトマネジメント上この改修の見積もりに2日+αでOKは出せないでしょう。中途半端にコーディングを実施して後で「やっぱダメでした」といわれるリスクを考えたら、ここで2ヶ月の工数をとるのは常識的な判断だと思いますが、いかがでしょうか？
だからSQLの技術が重要とおっしゃりたいのでしょうが、バグ入りのSQLを4ヶ月間放置されて間違いを指摘されたら
>関数の間違いなんて、わたしは茶飯ごとで（それじゃ駄目ですけどね）、上流はイメージを考えるのが仕事で、細かいことは実装・テストで潰してよってことで……。
といわれるエンジニアに「では2日+αでお願いします」とはよーいえませんって。
ちなみに問題のSQLですが、
CASE WHEN ABS(a.納品書消費税 - a.納品明細合計) >= 納品SEQ
の部分ですが、金額と順位の比較になっています。単位の違うものの比較ですが、なぜこの式が正しく動作するか説明する必要があるかと思います。 記事を一見しましたところこの部分の説明がありませんでした。
「オレの脳内では正しく動作するんじゃ」
ではコンサルは納得しないかと思いますし、トリッキーなコードと判断されかねません。
逆にきちんと説明できれば、任せて安心なエンジニアだと判断されるかと思いますが、いかがでしょうか？
・その他質問
>こんな細かいことを要求するシステムはそれなりの規模で、数人日は誤差ですから、私もまずゴネないと思います。
>ってな条件で考えるようになれって話です。
この『条件』というがのよく解らないので具体的に何を指しているのかご説明頂ければうれしいです。
・ユーザ企業と直接仕事をするのなら
本記事にはユーザ企業さんへのメッセージがありますが、用語の使い方には気をつけられた方がよいかと思います。実際に私はテクニカルアドバイザーとしてユーザ企業さんに様々なアドバイスを行う仕事もしていますが、SQL云々より、以下の様に用語の使い方に気を使っています。
>であれば、もしわたしが最初からコンサルとして入っていたら、「長くとも数分でできますから、締日に関係なく実行し、いつでもその時点のリアルな状況を把握できるようにしましょうか？」という提案になったでしょう。
リアルな状況把握というのはユーザにとってはまさに秒単位のことがあります。経営層に資料を提供するときに出力に分のオーダーがかかるものは、気軽にリアルとは言えません。
> つまり、仮締めともいえるし、シミュレーション機能ともいえます。コメントから分かる範囲での予想ですが、実現できれば経営判断に対するシステムの貢献度がまったく違うものになるでしょう。
仮締めの機能はシミュレーション機能とは言いません。
些末なことかもしれませんが、このような用語については、しっかりしたユーザさんは、ちゃんと把握されています。提案をする側にも、きちんとした意見を求めます。上記のように適当な用語の使い方をすると『こいつ思いつきでしゃべっているな』と思われて終わりです。実際に私は過去にこのような失敗を犯したことがあります。どれだけ技術力が高くても自分の主張を正確かつ平易に伝える能力が無ければユーザ企業さんと直接取引きするのは難しいと痛感しました。
また、
> テーブル設計を見た瞬間に「1から作り直すしかないですね、ごめんなさい」ってのも多いから、成功報酬で受けますよ。
というのも共感できません。ユーザ企業のシステム担当者は「ごめんなさい」といえない立場にあります。困っているときに助けてくれないエンジニアは、どれほど実力があろうとも信頼されない恐れがあります。いかがでしょうか？
余計なおせっかいかと思いますが、ちょっと気になったのでコメントしました。
通りすがりさん、すみませんでした。
基本的に、ざっくりイメージをつかむことなんですけれど、できない人はそもそも、SQLでやる検討をしてないのです。
上流のほんの少しのイメージの差で、夜間バッチを選んでしまったら運用設計にまで入ってしまったら、もう、影響大きすぎてひっくり返せないのですよね。
一瞬で判断ができるレベルまでやって欲しい。
すみません。
ちなみに、「通りすがり」というハンドルは……。
言い捨てるときに使うハンドルなので、戻ってくる気はないの意思表示と取ってしまいます。ある程度、区別できるハンドルでないと、答える方も精神的にキツイものがありますよ。
ryoさん、おはようございます。
ご意見ありがとうございます。
> 問題のSQLは上流の技術者は習得する必要があるのでしょうか？
問題のSQLは単純にコーディング能力を測るために作ったもので、これぐらいできなければ、誤った判断をしてしまう。
実際、現実のシステムは公開できない以上、架空のものになりますのでご勘弁ください。
> 実際の見積もりでは、きちんと動くものを作成するのに必要な工数を見積もり
> ます。のでそのように見積る必要があるかと思いますが？
> ちなみに、
> http://el.jibun.atmarkit.co.jp/g1sys/2009/03/sql-d43a.html
> では半日より長ければダメなようなことが書いてありますが、実際には半日
> 以上掛かるということになるのではないでしょうか？
そうですね。半日で見積もっていますよ。
それと見積りが大幅に変わるなら、経営者としては許しがたい差になりますね。
> (1)2日で出来るものに2ヶ月掛けるのはおかしい
> (2)SQL一発で出来ることにループを使うのはダメ
> (3)コンサルが間に入って変に工程を切られるのがウザイ
> (4)コンサルがSQLを覚えれば上記問題は解決される
> ということでしょうか？ 今ひとつ生島さんのストレスの要因が理解できません。
> 私も技術者で、(1)～(3)のことを感じることはありますが、それで(4)とする
> には、論理の飛躍があるかと思います。
どう飛躍があるのか分かりませんが、変に工程、機能を切られると、SQLは後からは選択できなくなる。変に切る理由は、コンサルがループをイメージしてしまった瞬間に根本原因があるわけです。
コンサルが安直にSQLを選択していて、実際の開発が始まってできない処理であることが判明すれば、大幅な工期遅れであったり、コンサルがイメージした性能は出ないわけです。
ですから、「できる」と判断したときにブレがあってはいけないのです。
> 確かに為替差損益の仕分けでなぜ2万とも思えなくないですが、実際に
> 2万ステップのコードがあれば慎重になるのも納得します。私がコンサル
> の立場でも「設計書を書いて仕様を明確にして欲しい」とお願いする
> ところです。これは無理な相談なのでしょうか？
基本設計は作ってますからね。それの直訳ですから書きようないですね。
テストは同じぐらい掛かりますけれど、パフォーマンスが違うからそれだけ小さくなりますね。
為替の仕分けは20パターンぐらいある結構難しい処理で、ループして処理すると本当に大変な処理です。
> 特定のエンジニアしかわからないトリッキーなSQLを書かれるよりベタに
> 作成してくれというもの無理な相談ではないかと思いますが、いかがで
> しょうか？
何をもってトリッキーというかですけれど、「こんなの出来ねーよ」って絡んでくる人と、「こんなのよりもっと難しくても使う」って人もいるわけです。
多数決でしょうが10年も前の技術をいつまでも「分からない、分からない」と言ってるからいつまでたっても「伸びない」って言ってるのですが。
> ここで2ヶ月の工数をとるのは常識的な判断だと思いますが、いかがでしょうか？
> だからSQLの技術が重要とおっしゃりたいのでしょうが、バグ入りのSQLを
> 4ヶ月間放置されて間違いを指摘されたら
> >関数の間違いなんて、わたしは茶飯ごとで（それじゃ駄目ですけどね）、
>> 上流はイメージを考えるのが仕事で、細かいことは実装・テストで潰して
>> よってことで……。
>
> といわれるエンジニアに「では2日+αでお願いします」とはよーいえませんって。
どうもすみません。
2ヶ月取ることは、可能であれば問題ありません。
問題は、2ヶ月の工期を取ってSQLを選択できるかです。
機能、工程の分け方の粒度が変わったらSQLではできなくなる、「その分け方は上流のほんの一瞬のイメージで決まっている」ところに問題があります。
> CASE WHEN ABS(a.納品書消費税 - a.納品明細合計) >= 納品SEQ
>
> の部分ですが、金額と順位の比較になっています。単位の違うものの
> 比較ですが、なぜこの式が正しく動作するか説明する必要があるかと思い
> ます。 記事を一見しましたところこの部分の説明がありませんでした。
消費税の差額が出た場合、明細金額の大きなものから順に1円ずつ増減して合計をあわせます。
ですから、差額の絶対値と順位を比較しています。
トリッキーではなく、ループしても同じIF文を書くはずですけど……。
トリッキーでないコードを示していただければありがたいです。
>> こんな細かいことを要求するシステムはそれなりの規模で、数人日は誤差
>> ですから、私もまずゴネないと思います。
>> ってな条件で考えるようになれって話です。
> この『条件』というがのよく解らないので具体的に何を指しているのか
> ご説明頂ければうれしいです。
SQLを選択するかどうか、選択したときのメリット・デメリット、しなかったときのメリット・デメリット。
何度も書いていますけれど、上流が問題程度を会話のペースで理解できないと、SQLを選択できない局面は一杯あるのです。「私はそんなことはない」って言う人も多いけれど、その人は「局面に立って誤った判断をした」と気づく能力もないわけです。
>> であれば、もしわたしが最初からコンサルとして入っていたら、
>> 「長くとも数分でできますから、締日に関係なく実行し、いつでもその
>> 時点のリアルな状況を把握できるようにしましょうか？」という提案に
>> なったでしょう。
>
> リアルな状況把握というのはユーザにとってはまさに秒単位のことがあります。
そりゃありますけれど、この顧客は数時間のバッチ処理かの選択の局面で、「長くとも数分」と話して勘違いする？
基本的な日本語の使い方だと思いますけれどね。
>> つまり、仮締めともいえるし、シミュレーション機能ともいえます。
>> コメントから分かる範囲での予想ですが、実現できれば経営判断に
>> 対するシステムの貢献度がまったく違うものになるでしょう。
>
> 仮締めの機能はシミュレーション機能とは言いません。
「ともいえます。」というのは、そのものではないけれど似たものを指すときに使うのではないでしょうか？
基本的な日本語の使い方だと思いますけれどね。
>> テーブル設計を見た瞬間に「1から作り直すしかないですね、ごめんなさい」
>> ってのも多いから、成功報酬で受けますよ。
>
> というのも共感できません。ユーザ企業のシステム担当者は「ごめんなさい」
> といえない立場にあります。困っているときに助けてくれないエンジニアは、> どれほど実力があろうとも信頼されない恐れがあります。いかがでしょうか？
そりゃ、費用の問題ですね。
「1から作り直すしかない」のに、1から作り直す費用が出なかったら、ごめんなさいとしか言えませんね。
1から作り直すなら私がやる必要もないし。
「1から作り直すしかない」のに、どうやって助けるのか教えて欲しいのですが？
通りすがり
>答える方も精神的にキツイ
それは失礼いたしました。
取り急ぎ。
次からは適当なハンドル付けますね。
ryo
生島さん
おぉ、早速のご返信ありがとうございます。
ただ、慌てて返信しなくても、前の私のコメントじっくり読んで返信いただけばと思います。
それと私の質問の答えていないところがありますよ。きちんとした議論（炎上）をしたいのなら質問に答えて頂かないと。
質問の回答とコメントを、
>問題のSQLは単純にコーディング能力を測るために作ったもので、これぐらいできなければ、誤った判断をしてしまう。
>実際、現実のシステムは公開できない以上、架空のものになりますのでご勘弁ください。
架空が許されるなら、追加で質問があります。例えば割賦単位が3円で振り分けるような場合、どのようなSQLになるのでしょうか？（私はこのようなSQLは書きたくありません・・・）
>そうですね。半日で見積もっていますよ。
>それと見積りが大幅に変わるなら、経営者としては許しがたい差になりますね。
ですから、ちゃんとテストしたら1日は掛かるでしょうというのが私の前のコメントになります。予定工数の倍かかったらアウトだと思いますがいかがでしょうか？
>どう飛躍があるのか分かりませんが、変に工程、機能を切られると、SQLは後からは選択
（中略）
>ですから、「できる」と判断したときにブレがあってはいけないのです。
すんません、何を言っているのか理解できません。
>基本設計は作ってますからね。それの直訳ですから書きようないですね。
この議論で解ったことですが、なぜコンサルが『設計書を書いてくれ』というのか理解できました。大変失礼ですが、生島さん、ときどき何を言っているのか解らないから『レビューが必要だ』とコンサルに判断されたようですね。
>テストは同じぐらい掛かりますけれど、パフォーマンスが違うからそれだけ小さくなりますね。
>為替の仕分けは20パターンぐらいある結構難しい処理で、ループして処理すると本当に大変な処理です。
うーん、だからOLAP関数を使ったSQLが絶対に必要という部分がわかりません。逆にオブジェクト指向で考えるのなら仕分けの部分を仮想関数で組んで・・・とかにもなりそうですが、そういうのはお嫌い？（すんません、ここは遊んでます。）
>何をもってトリッキーというかですけれど、「こんなの出来ねーよ」って絡んでくる人と、「こんなのよりもっと難しくても使う」って人もいるわけです。
つまり、エンジニア間でコンセンサスが取れていない技術に対して、「こうあるべきだ!」といっていると理解してよろしいでしょうか？
>多数決でしょうが10年も前の技術をいつまでも「分からない、分からない」と言ってるからいつまでたっても「伸びない」って言ってるのですが。
この手の技術の浸透具合は予測困難です。15年程前は、『オブジェクト指向？なにそれ？』ってな感じでしたが、今では当たり前になってますよね？ 世間が自分に合わせていないからと言って愚痴るのはどうかと思います。
>どうもすみません。
>2ヶ月取ることは、可能であれば問題ありません。
(中略）
>んの一瞬のイメージで決まっている」ところに問題があります。
すんません、意味が解りませんでした。
>消費税の差額が出た場合、明細金額の大きなものから順に1円ずつ増減して合計をあわせます。
これについてはOKです。
>ですから、差額の絶対値と順位を比較しています。
前の部分とこの部分に飛躍があるのです。
で、このように話をされると私の質問（おそらくコンサルの質問）にきちんと答えられてないと判断されても仕方がないでしょう。単位が一致しない件については、
CASE WHEN ABS(a.納品書消費税 - a.納品明細合計) >= 納品SEQ * 1 -- 1円
この1円は、割賦単位で、1なのでコードでは省略されている。比較の単位は共に円である。と説明すれば、喧嘩越しにならなくても（ループの話を持ち出さなくても）相手に通じるかと思いますが、いかがでしょうか？
ちなみに、トリッキーと言っている＝コードを批判している、と考えるのは早計です。
>SQLを選択するかどうか、選択したときのメリット・デメリット、しなかったときのメリット・デメリット。
>何度も書いていますけれど、上流が問題程度を会話のペースで理解できないと、SQLを選択できない局面は一杯あるのです。「私はそんなことはない」って言う人も多いけれど、その人は「局面に立って誤った判断をした」と気づく能力もないわけです。
ええ、私はそんなことないと思います。やはりここは具体的な例を挙げて頂かないと永遠に平行線のようですね。
>そりゃありますけれど、この顧客は数時間のバッチ処理かの選択の局面で、「長くとも数分」と話して勘違いする？
>基本的な日本語の使い方だと思いますけれどね。
もとのコメントの趣旨を誤解されています。『長くとも数分』というのは『リアル』ではないと言っています。で、このように日本語があいまいな方がきちんとしたコードを書くかどうかとうのに疑問を持つ人がいるということが言いたいことです。
>「ともいえます。」というのは、そのものではないけれど似たものを指すときに使うのではないでしょうか？
シミュレーションの意味をきちんと調べられることをお勧めします。
>「1から作り直すしかない」のに、どうやって助けるのか教えて欲しいのですが
フフフ、この辺りは企業秘密ですぜだんな。
誤解があったようで（というかわざとそうしましたが）実は、私は生島さんが書かれたSQLは「上手い！」と思いました。特に例の
CASE WHEN ABS(a.納品書消費税 - a.納品明細合計) >= 納品SEQ
は実は私には盲点でした。
それだけに、ご自身の自説を他者にきちんと解り易く説明できれば、余計なストレスがかからず円滑にプロジェクトを進めることができるのでは？と思った次第です。特に今回のように『絶対にOLAP関数を使わなければならない』と思われるところがあるのでしたらそれをきちんと説明すれば通常は先方も納得してくれるのでは？と思った訳です。
最初から地力はある方だというのはわかったのですが、それだけに『惜しい・・・』と思いました。で、同じ70年生まれということもあり、余計にコメントしてみました。
では
通りすがりさん、ども。
多分、通りすがりさんにだけ、はぐらかしたように書いたと思います。
すみませんでした。
他の方も、書き逃げするつもりじゃないなら、後で分かるハンドルをつけてもらうとありがたいです。
> 架空が許されるなら、追加で質問があります。例えば割賦単位が3円で振り分ける
> ような場合、どのようなSQLになるのでしょうか？（私はこのようなSQLは書きた
> くありません・・・）
3円は業務内容からはあり得ないので書けない。丸め単位にならないと誤差配賦の意味がないので、10円とか100円ならあり得ます。* 10とするだけですね。
仮に3円単位で丸めるという処理があって、誤差が必ず3nになるならば、* 3 ですね。
もっと膨らまして書くことはできます。たとえば、赤黒が混じったときなどというパターンです。これの解説をタダでしろと言われてもちょっとしんどいので書いてませんけどセミナーでやる予定。
>> そうですね。半日で見積もっていますよ。
>> それと見積りが大幅に変わるなら、経営者としては許しがたい差になりますね。
>
> ですから、ちゃんとテストしたら1日は掛かるでしょうというのが私の前の
> コメントになります。予定工数の倍かかったらアウトだと思いますがいかが
> でしょうか？
30分で書いてそのまんまアップしてます。DBを作ってないからチューニングとかやってないし。
書いてみて精々3時間30分だと思いますので、0.5人日です。
まぁ、1人日だろうが誤差の範囲だと思いますけどね。
>> ですから、「できる」と判断したときにブレがあってはいけないのです。
>
> すんません、何を言っているのか理解できません。
上流で「できる」と判断した以上、できなければならないわけです。
そのため、よほど自信がないと「できる」とは判断できませんね。
コメントで15分でできるという方も登場しましたが、その辺になると全く違うゴールが見えるし、運用設計など本来の上流工程がまるで違うものになるのです。
> >基本設計は作ってますからね。それの直訳ですから書きようないですね。
>
> この議論で解ったことですが、なぜコンサルが『設計書を書いてくれ』
> というのか理解できました。大変失礼ですが、生島さん、ときどき何を
> 言っているのか解らないから『レビューが必要だ』とコンサルに判断さ
> れたようですね。
そうなんですかね。
> つまり、エンジニア間でコンセンサスが取れていない技術に対して、
> 「こうあるべきだ!」といっていると理解してよろしいでしょうか？
そうですよ、技術者が多数決を意識していたら、いまだに地球は平らで太陽が地球の周りを回っていることになりますね。コペルニクスやガリレオが命を掛けて主張したから今があるわけです。
開発方針で言えば、熟練者が行き着く地点が、その技術の限界地点でしょう。
技術者なら、できる人を見たらすぐにでも「パクらんかい！」って言ってるわけです。
もっとも、技術は良くても負けるものもあります。
VB6が流行った当時、明らかにDelphiの方が上でした。
しかし、導入するかどうかに壁がありますから、結局、VB6が勝ってしまった。
で、何度も書いているけれども、SQLは導入済みで、壁は技術者の意識でしかないのであれば、それを主張する技術者は怠慢ってことで大問題でしょう。
>> どうもすみません。
>> 2ヶ月取ることは、可能であれば問題ありません。
> (中略）
>> んの一瞬のイメージで決まっている」ところに問題があります。
>
> すんません、意味が解りませんでした。
何度も書いていることですけれど、たとえばご自身も書いてらっしゃいますが
> 逆にオブジェクト指向で考えるのなら仕分けの部分を仮想関数で組んで・・・
を前提に考える瞬間というのがあるのです。
それは顧客の口から要望が出た瞬間に、そこに居合わせた上流のイメージで決まっています。
その場で居合わせた全員（営業でさえ）が必ず、難易度を測って（粗い見積り）話をしています。難易度（工数）も、パフォーマンスも辺りをつけれなかったら、「帰って検討します」しか言えないし、下手に言質を与えてはいけないから、その先何の話もできないはずです。それじゃ「ガキの使い」ですね。
で、問題ぐらいができないと、その緊張の瞬間にSQLのパターンで難易度を測ることは不可能なのです。
そのため、オブジェクト指向を前提としたモロモロの決め事をされていしまう。それらの決め事は小さいようで、もうひっくり返せない既成事実になります。
とにかく、場合によっては、工数もパフォーマンスも著しく変わる可能性があるのに、（馬鹿高いライセンス費を出して顧客に買わせて）RDBMSは採用しておいて、技術者のスキルのために「SQLで処理する」という選択肢がなくなることがおかしいでしょう。
結果的に選ばなくても良いのですけれど、問題のSQLが会話のペースでイメージできないという人は、検討の結果SQLを選ばなかったのではなく「スキルが足りず選べなかった」ということになります。
> CASE WHEN ABS(a.納品書消費税 - a.納品明細合計) >= 納品SEQ * 1 -- 1円
確かにおっしゃるとおりです。
が私の拙い経験では、上の意味が分かる人は元のものでも分かると思うし、元のものが分からない人は、これでも分からないと思いますよ。
# 今、見たら、SEQってエリアスつけているのにRANKを
# 使うってひどい話やな～（苦笑）
私は、他人の想像力を過大評価してしまうところは確かにあります。
そもそも、自分は27歳デビューの素人上がりなので、自分のできることはみんな絶対にできる、分かる、という思いが猛烈に強いし、クドく解説されるのは馬鹿にされているような気がして嫌いという子供じみた発想がかなり深く染み付いてしまったので、あまり細かい説明はプロに対して失礼と無意識に思ってしまう。
これが問題なのはようやく最近分かってきました（が、治らんでしょうね）
これを読んで分かってくれるユーザなら相当できるシステム部門の方々で、多分、一般の技術者よりSQLのレベルは高い（ことが多い）し……。
まぁ、こんな社長でも6割は直の受託開発でやっていますし、このご時勢でも新規が入ってくるぐらいには、顧客相手には簡単に詳しく話するのですけどね。
弊社では大きくても3000万までが限界で、それ以上の規模の案件のときには、基本設計か詳細設計からです。で、それまでの資料を見ると、要件定義のおそらく瞬間的に決まった（というか決め打ちされた）覆せないモロモロの確定事項にイライラしているのです。
シミュレーションは現実とは違う、仮のパラメータ（条件）で処理して仮の結果を出すことですから、「締め日が違う」だけでシミュレーションといえますよ。
本文では、他に機能を付け加えて切り口を変えようとしているわけですね。
もっとも、そんな言葉の定義なんて、私にとってはどうでも良いのです。
続きは記事にもう少しまとめて書きます。
ryo
ちょっとは考えて返信されたようで、文面は読みやすくなりましたが、まったく裏の取れていない発言でがっかりです。
議論（炎上）を期待するならもう少しきちんとした発言をして頂かないとこちらとしてもつまらないです。
無視しようかと思いましたが、私の発言で撤回したいところがありますのでコメントします。
>3円は業務内容からはあり得ないので書けない。丸め単位にならないと誤差配賦の意味がないので、10円とか100円ならあり得ます。* 10とするだけですね。
仮に3円単位で丸めるという処理があって、誤差が必ず3nになるならば、* 3 ですね。
割賦単位が10円なら、
CASE WHEN ABS(a.請求書消費税 - a.請求明細合計) >= 請求SEQ * 10
THEN SIGN(a.請求書消費税 - a.請求明細合計) * 10 ELSE 0 END -- バグ入り
と実装できるということでしょうか？、この実装には少なくとも2つ問題があります。
ひとつはご自身でご指摘されています、3円のときと同様の問題です。
ご自身の発言が相手にどう思われるか考えておられないようなので、失礼ながら言いますと、
このような矛盾のある発言をされると、
『元のSQLは本当に生島さんが作ったのだろうか？』
と思うのです。
>30分で書いてそのまんまアップしてます。DBを作ってないからチューニングとかやってないし。
>書いてみて精々3時間30分だと思いますので、0.5人日です。
これはテストなしの工数ですよね。追加したらもっと掛かるでしょう。
>まぁ、1人日だろうが誤差の範囲だと思いますけどね。
http://el.jibun.atmarkit.co.jp/g1sys/2009/03/sql-d43a.html
には、
>あなたの見積もりが半日より長ければ、プロジェクト全体の差は、経営者として楽観視できるものではありません。どれぐらいの利益と、まっとうなプロジェクト運営（定時退社）に繋がるかを考えてみてください。
とあります。こちらも思ったことを言いますと、
『普段はえらそうなことをいいよるが納期が遅れたらなんやかんやで言い逃れするタイプやな』
と思いました。
でこのような発言にブレのある人が、
>>> ですから、「できる」と判断したときにブレがあってはいけないのです。
>>
>> すんません、何を言っているのか理解できません。
>上流で「できる」と判断した以上、できなければならないわけです。
といってもまったく、まったく説得力がないです。
ちなみに、ソフトウェアエンジニアリングの観点から一般論として、
『上流工程で混入されたバグの対応にはコストが掛かる』
という話は理解できます。それと
『上流工程では1つもバグがあってはならない』
という話は違います。
上流工程では1つもバグがあってはならないという前提で話をするエンジニアは『未熟』としかいい様がありません。
> > >基本設計は作ってますからね。それの直訳ですから書きようないですね。
> >
> > この議論で解ったことですが、なぜコンサルが『設計書を書いてくれ』
> > というのか理解できました。大変失礼ですが、生島さん、ときどき何を
> > 言っているのか解らないから『レビューが必要だ』とコンサルに判断さ
> > れたようですね。
>そうなんですかね。
頭から否定しないということは、思い当たる所があるようですね。
本記事で生島さんは、上流のエンジニアの評価（というか評価基準の設定）を行っている訳ですが、同様に（それ以上にシビヤに）、上流のエンジニアは、下流のエンジニアの評価を行っており、あの手この手で、探りを入れてきます。私の質問は、そういった趣旨で行ってるものもあります。
設計書を書かせたり、そのレビューを行うのは工数がかかります。それをわざわざするのは理由があります。
『こいつは大丈夫だと』判断されたエンジニアにはレビューされないでしょう。
組織上やプロジェクト管理上、レビューが必要なこともありますが、非常に形式的になるか、
他のエンジニアを同席させて勉強会になったりするでしょう。
逆に『こいつは危険や』と判断されたエンジニアには手厚くフォローされて当然でしょう。
> 技術者なら、できる人を見たらすぐにでも「パクらんかい！」って言ってるわけです。
これも非常に言いにくいことなのですが、つまりあなたが、できない人、だからパクられないのでしょう。
一般論で話をすると、OLAP関数を勉強するかどうかについては個人の勝手でしょう。
私はどうかという話ですが、知識としては覚えましたが、使う必要性を感じていませんでした。
問題のSQLは上手いとは思いますが、前提がおかしいので、そのSQLの例を出されてOLAP関数は重要だと言われても説得力を感じないのです。
で、他にOLAP関数の利用例を出してくれることを期待しましたが、生島さんにそういった行間を読む力はなかったようで、残念です。
>何度も書いていることですけれど、たとえばご自身も書いてらっしゃいますが
>
>> 逆にオブジェクト指向で考えるのなら仕分けの部分を仮想関数で組んで・・・
>を前提に考える瞬間というのがあるのです。
>それは顧客の口から要望が出た瞬間に、そこに居合わせた上流のイメージで決まっています。
（中略）
>とにかく、場合によっては、工数もパフォーマンスも著しく変わる可能性があるのに、（馬鹿高いライセンス費を出して顧客に買わせて）RDBMSは採用しておいて、技術者のスキルのために「SQLで処理する」という選択肢がなくなることがおかしいでしょう。
この一連の発言をみて『あ～この人、過去にJavaかなんかの開発でプロジェクトが火を噴いたな』とか思うわけです。
で、あったことを率直に言ってくれるとこちらも、『あ～解る、昔のJavaってダメだったよね』とか判断することができるのですが、
根拠のない上流エンジニア批判をされるとこちらとしては、『元請から切られて逆恨みしているのかな?』と変な勘ぐりをしてしまうわけです。
>確かにおっしゃるとおりです。
（中略）
>これが問題なのはようやく最近分かってきました（が、治らんでしょうね）
ここまでわかっているのなら、本文で、
>そんな詐欺師にならず、まっとうな上流技術者になるなら、最低でも
>
>http://www.g1sys.co.jp/seminar090515.html
>
>http://www.g1sys.co.jp/seminar090515_answer.html
>
> これぐらいできなくてはいけません。
というのはそろそろ撤回されることをお勧めします。詐欺師というのは犯罪者です。根拠もなしに人を犯罪者にしてはいけません。
>まぁ、こんな社長でも6割は直の受託開発でやっていますし、このご時勢でも新規が入ってくるぐらいには、顧客相手には簡単に詳しく話するのですけどね。
ちょっと心配してましたが、それはよかったですね。のでこちらも遠慮なく炎上に協力します。もっともこれで最後ですが。
> シミュレーションは現実とは違う、仮のパラメータ（条件）で処理して仮の結果を出すことですから、「締め日が違う」だけでシミュレーションといえますよ。
> 本文では、他に機能を付け加えて切り口を変えようとしているわけですね。
では質問しますが、締め日を変えることにより得られる有益な情報ってなんでしょうか？
私には結果資金繰りが変わるということぐらいしか思いつきませんが？
（それをもってシミュレーション機能って・・・）
で、前回私は、
>>最初から地力はある方だというのはわかったのですが、
といいましたが、間違えておりました。撤回します。
#まぁオレもまだまだ人を見る目がないということで・・・。
ちょっと無礼な発言もありましたが、炎上を期待されていたようですのでお許しを、ちなみに私はこれで最後にします。
では、ごきげんよう。
ryoさん、ども。
私は、細かいことは気にしてないです。えらいすみません。
本文の主旨は、「でっかい方を見ろ」ってことなんですけど、まったく伝わってないのは悲しいです。
お客さんが言葉尻で勘違いしたなら正せばいい。
そんなことでプロジェクトは変わらない。
火を噴くプロジェクトをなくしたいだけです。