ベンチャー社長で技術者で

saki1208です。

ウチでは、例えバッチ処理であっても、一回の実行に5時間もかかる
ようでは納品物として認められないでしょう。常識的に考えて、異常
としか言いようがないです。
もちろん、PCのスペックやデータ量にもよりますから一概には言えな
いのですが、それにしても異常です。

作る側として、おかしいと思う感覚がないのでしょうか?

確かにこのようなSIerが増えると、業界全体が信用されなくなり、悲
しいことになりますね。

saki1208さん、こんばんは。

まぁ、SQLを覚えたらというのは、パフォーマンスだけではないのですが、
なかなか、説明するのは難しいです。

成功ラインを決めるコンサルに、その違いが分からないというのは話に
ならないのですけどね…。

2時間が2秒ってのもありますから、とてつもなく下手糞も存在します
けれど、普通の技術者でも、私の経験でSQLにロジックを寄せたら、
大体20倍のパフォーマンスの差が出ます。

なんと言いますか5時間はありえないでしょうけれど、オンライン処理を
選べるのは数十秒まででしょう。

と考えると、20分ぐらいのものは大体、SQLに直せば60秒ぐらいになり
ます。1990年代なら果てしなく下手糞もいたし、ハードもきつかった
ので、もっとひどい差がついたのですが、この差は現在でも大きいと
思います。

成功といわれているプロジェクトでも、突っ込みどころは山のように
ありますが、なかなか突っ込むチャンスはありません。

saki1208です。

まあ、確かにパフォーマンスの話が一番解りやすいので、いつもその話が
多くなりがちですね。
本当の良さは、もっと別のところに…
# 生島さんはいつも声を大にして仰ってますけど。

ビジネスロジックの実装とUIの切り離しがきちんとできれば、処理の実装
にUIが影響されることも少なくなりますし、内部ロジックの変更に今ほど
神経を使う必要もなくなるのではないかと…

私は10年ほど前から「どうすれば?」に取り組んでいるつもりなのですが、
周りからは中々理解を得られません。逆にUIにビジネスロジックが鏤めら
れている方が解りやすいそうです。
# そのせいでいつも苦労するにも関わらずです。

業務システムの一般的なチェックロジックなんてどんなシステムでも殆ど
同じだし、特殊なパターンだけ外部アセンブリとかにしてリフレクション
使って呼び出すとかで良い気がするのですけど、なぜか一から作りたがる
んですよねぇ。
# 多分、人月でしか計算できないからでしょうけど。

私はSQLに限らず情報処理技術全般を学ぶべきだと考えております。
プログラム言語としては・・・
命令型・関数型・論理型・問い合わせ型・スクリプト言語の5系統を2個づつぐらいは修得して欲しいです。
そうしないと、オブジェクト指向分析／設計なんて出来ないです。
実装を意識しないと無知でもいいは別物です。
オブジェクト指向分析／設計の際に、明後日の方向を向いていれば駄目なのです。
最終的には電子計算機が処理するのですから、その特性を踏まえた分析／設計をしないと駄目なのは当然の事です。
他にもOS知識・ネットワーク知識・データベース知識・セキュリティ知識は必須です。
そもそも上流／下流なんて分類馬鹿げています。
片方だけやったら駄目なのは当たり前です。
片方の車輪でシステム開発という名の車は走れません！
四の五の言わずに両方やればいいのです。
そうすれば、頭の中で最終結果がシュミレーション出来るようになります。

工数を減らそうとする私が馬鹿なのかとも思わなくはないけれど、
上流と下流が同じ会社というのはほとんどないわけで、上流なら
全体工数を下げることが、もっとも自分の利益にかなっているはず。

上流は人月関係ないはずなんですけどね。

彼らの能力不足で自分たちの職域で問題を起こしているのですが、
それを正すのではなく、覆い隠すことができるのが上流の仕事って
ことなんですね。

やっぱり、上流、下流ではなく、内部、外部と分けるべきでしょうね。

ちょくちょく拝見させていただいているのですが、
生島さんがおっしゃっている立場や気持ちについては
よく理解できます。
ただ、細かいことになって申し訳ありませんが
例に出されているＳＱＬサンプルについて疑問があります。
消費税配賦対象になるランク境界の明細に同一金額が
２行以上ある場合にこの方法では余分に加算されてしまわないでしょうか。
（例えば、消費税丸め方法が切り捨て・納品書単位で
　明細金額が90円・90円・40円の３明細しかないような場合）
前々から気になっていたのですが、頻繁にリンクされているので
今頃になってからですが質問させていただきます。
私の理解不足であれば申し訳ありません。

今回は、長い記事で「えらい気合い入ってるな・・」。ほぼ頷きながら、でも少し違うなぁ・・なんて思いながら読ませていただきました。

少し違うと思った中から、特に「ちょっと違うけどかなり違うかもしれない」と感じた部分についてコメントさせていただきます。
----------
コンサルや上流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と申します。

生島さんのコラムは、非常に勉強になります。いつも興味深く読ませて頂いております。

ところで、

＞大阪じゃ集まりそうもないから、平日2日間（16、17日）、土日2日間（18、19日）に東京で

ま、マジですか・・・。

と言うのも、私は現在大阪市内で働いております。
前回のセミナーにも参加しようか迷ったのですが、その当時はまだ生島さんについてよく存じ上げておらず、見送りました。

それからは、暇があればコラムだけでなく、コメントもかなりの部分を拝読致しました。生島さんの考え方には、共感できる部分が非常に多く、「あなたは俺か！？」と、時々思ってしまうぐらいです。

そんなこんなで、次のセミナーには絶対参加する！！と常々考えていたところの東京開催のお知らせを聞いて、こんな事なら前回参加しとけば良かったと少し後悔しております。

しかし、善く善く考えてみると、７月ならば連続休暇（夏休み）を取得できます。ですので、都合が合えば参加させて頂きたいと思います！

それでは。

がると申します。
「高いレベルのSQL」というものの定義に興味を持ちました。
個人的には…正直なところ。DBMS毎の差異(或いは方言)やスケールアウト、ビジネスロジックの散逸などから、「SQL一発でゴンと出す」という状況に、必ずしも是と言い切れないものがある、と感じております。
無論様々な現場環境などあるかと思いますので。生島勘富さんのお考えなどを窺う事が出来れば、と思い書かせていただきました。
お時間のある時にでもご見解など窺えれば幸いです。

tkさま、お世話になります。

大阪だったら……。
余り期待されても困りますけどね、info@g1sys.co.jpにメール
いただければ、いろいろとご相談させていただきます。

がるさん、はじめまして。

> 正直なところ。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です。

＞もしかすると、某プロジェクト向けに（社内じゃないけど）やるときに参加してもらうパターンもありかな……。

おおお！是非、期待しております。

今からメールお送りします。

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さん

コメントありがとうございます。
ジーワンシステムの生島です。

大阪はこっそり弊社の小汚い事務所で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と申します。

生島さんのブログをみるかぎり、コンサルタントと何かあったようですが、
やり取りを具体的に書いて頂いた方が共感（反論、炎上）を得られるのではないでしょうか？

炎上を期待しているようなので疑問に思ったことを質問してみます。

・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はとても大事だから覚えろ
ということであってますか？
誤読でしたらご指摘頂きたく存じます。

(以下正しいと言う認識で)
私の場合、追加要件でついた枝葉のせいでブレることもありえますから、「まぁ行けるな」「ちょっと無理かな、難しいかな」程度にしか掘り下げないです。

で、上記まとめが正しいのであれば特に異論は無いのですが、そうじゃない世界があるのですか？

いや、ま、確かに某成果主義崩壊な会社あたりでそういう世界があったような気もしますが、そうじゃない世界もいっぱいあるでしょうに。
ダメな会社なんて、放っておけば潰...

余計なお世話ですが、喧嘩なんて時間の無駄で、迂回した方が早いんじゃないかなあと。

生島さん

ご返信ありがとうございます。ちょっと長めになりましたがコメントします。
まぁ、プチ炎上ってことでご勘弁を。

・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から作り直すしかない」のに、どうやって助けるのか教えて欲しいのですが？