どうも、インドリです。
生島さん、この問題のテーブルの記述のところなんですが、売上明細テーブルの納品書NOは売上IDではないでしょうか？
細かいツッコミで済みません。

インドリさん、ありがとうございます。

ホントですね。
間違ってますわ。
失礼しました。

先ほど言い忘れていましたが、OLAP関数は使わないほうがいいと思います。
たぶんあの○関数を使うと思うのですが、同一金額がある場合データの整合性がなくなります。
この場合、UPDATEを2回使う方法の方が汎用性の点から言ってもいいかと。

余計な突っ込みはさておき、このレベルのSQLを会話ペースで出来るのは凄いと思います。
さすが熟練の技術者です。
この業界の会社は何故か熟練者に対して敬意を払いませんが、経験ってやっぱり大事ですね。

インドリさん

順位を飛ばさない方の関数でいけます（これも確かSQL99の標準関数のはず）
他に、金額のORDER BYの後ろに主キーを入れてもいいはずですけれど、バージョン(Oracle)によってちゃんと評価されなかったような気もする、これはうろ覚えで、インネン付けてることになるかな……。

これは失礼致しました。
順位を飛ばさない方の関数を忘れていました。
SQL99にもあるとなると、その関数を積極的に使うべきですね。
主キーを入れる方法については、データの消滅も考慮すると危険だと思います。

saki1208です。

インドリさん
>この業界の会社は何故か熟練者に対して敬意を払いませんが、経験ってやっぱり
>大事ですね。
ちゃんとできる人もいますが、圧倒的にできない人が多いからかと。
特にバブル期を経験している人には多い気がします。
# どうやら私も生島さんと同年代ですが、私の周りにはできる人2割、その他2割く
# らいですね。やっぱり、2:6:2なんでしょうかね。
# できるほうにカウントされてるとうれしいな。
# まぁ、年齢はあまり関係ないですが(w)

生島さん
>バージョン(Oracle)によってちゃんと評価されなかったような気もする、これはう
>ろ覚えで、インネン付けてることになるかな……。
ODP経由の場合には、分析関数が正しく動作しないことがあるようです。
少なくとも10gではありましたよ。orz

インドリさん
Order By に主キーを入れるのはユニークになりさえすれば良いのでデータが飛んでも問題はないはずです。
saki1208さんがおっしゃるとおり、正しく動作しないことがあったりするのでお勧めはしないです。
OLAP関数はかなり強力なのですけれど、使う人が少ないのでベンダーのデバッグも進まないのかもしれませんね。標準関数ですから積極的に使うべきだと思っています。

saki1208さん、ども。

同世代ですか、私は1970年生まれで高卒で働き出したから、バブルの経験も若干あるようなないような。

できない人が多いのは、ITバブルの所為もあるよね。
とにかく人が足りないので、どんなに向かない人もナントカ使うことが目的化してしまった。

向かない人を向くように教育するのではなく、向かない人を集めても人海戦術で終わらす方法は、どう考えても合理的ではないですよね。

それで、SQLをエクセルで教える方法を、今、煮詰めています。
上の問題の内容が理解できる人（業務理解ができなければ無理）であれば、1日のセミナーで1時間ぐらいで解けるようなスキルがつく内容と思っています。

また、自分基準で考えていると笑われるかもしれませんが、本当に簡単なんです。

saki1208です。

訂正です。
誤：私の周りにはできる人2割、その他2割
正：私の周りにはできる人2割、その他8割

生島さん
>私は1970年生まれで高卒で働き出したから、バブルの経験も若干あるようなないような。
最初は異業種だったんですよね。
で、ご自分で勉強されたと...
そういう方は当てはまらないと思います。(w)

最初から同業種でも、自分で修羅場をくぐってきた人たちは基本的にできる人になって
るようですよ。できない人は流れに身を任せていた人みたいです。

>　ホンマ上流の倍ぐらいの単価でもおかしくないのにな～。 ← これが一番のホン>ネ（笑）

まったくそうですね。
職業はいいませんが、私も、自分の仕事はもっと単価が高くてもいいはず！などと考えています（笑）。
ただ悲しいかな。
市場の需要が少ないので、いくら貴重なスキルを持っていても、単価が安い。
しかし、その少ないお客さんに対して、丁寧に仕事していくしかないですよね（笑）。
私のスキルの需要！もっと上がれ！！

前にいった事ですが、インクリメントID列使用と勘違いしていました。
優先順位を決定するためのORDER BYならばIDありですよね。

>ちゃんとできる人もいますが、圧倒的にできない人が多いからかと。
特にバブル期を経験している人には多い気がします。

確かに（笑）
saki1208さんの言うとおりで、年取っていても駄目な人はいますよねｗ
というか、ネットでは凄い人が沢山居るけど、現実では駄目な人しかあったことがありませんorz
ということは、昔から情報産業はルーズなんですね（溜息）
それでもシステム偽装が社会的に問題視されないんですよね。
世間の節穴ぶりにあきれます。
多分システム偽装する会社を優遇しておきながら、だいぶ後でシステム偽装だって騒ぐんだろうね・・・

みなさま、どうも。

できない人たちが上まで行っちゃってしまった業界ですから、正しい評価はしようがないですよね。それでも、なんとかムーブメントを起こしたい。「@IT自分戦略研究所」で、検索キーワードのトップは「データベーススキル」なので、ちょっとは注目がくればと思っているのですけれど。

ここでコメントをいただける方は、マイノリティでできる方の人なのでしょう。

本当は、サイレントマジョリティの意見が聞きたいのですけれど、ハードル上げすぎかもしれません。

>本当は、サイレントマジョリティの意見が聞きたいのですけれど、ハードル上げすぎかもしれません。

了解しました。では私が会った上流技術者になりきってありがちな意見を書きます。

SQLを勉強すればいいのは分かっていますが、例え勉強したところで給与は増えません。
それどころか、SQLを知らない上司から睨まれますので、結果として下がる恐れすらあります。
それに現実に評価されるのは、口だけのゴマすり野郎です。
それならば、例え馬鹿と言われても上司のご機嫌を伺いながら出世する方を選びます。
ちなみに、脳内プログラミング自体できません（>_<）

インドリさん

東京の方は殺伐としているのですね。
大阪は基本的に本社にいけなかった人と、東京から一時的に勉強に来ている人が居るので、まだ、のびのびとやっているというか、露骨なゴマすりは見ないように思う。
逆に、チンタラ率も高いかもしれませんね。

生島さんは技術者でもあるのでいいのですが、社長が「ITって何か儲かるな」というレベルの人の会社が多く、そういった会社は能力の評価が出来ないので「気に入った奴を出世させる」という馬鹿げた手法が採られているようです。
あと、日本人特有の偉い＝管理者という先入観を取り除かないと、ゴマすりが一番の出世方法となって技術を磨かないと思います。
この2つを何とかしない限り彼らはは学習しないと思います。
学習しない方が収入が増えるのですから・・・
SQLを学習しない上流技術者たちはその方が儲かるからしているようです。

この原因はやはり「お客様が看板しか見ず、品質も気にしない。」という事だと、私は思えてなりらないのですが、生島さんはどうやったらお客様が看板だけ見て偽装商品を買う行為を止めると思いますか？

誤差配賦はSQLではかなりやりにくい機能なので書いてみましたが、これぐらいのができるようになればできない機能を探す方が難しいぐらいです。
わたしは途中でユーザの判断が不要ならほとんどSQLでできる、もちろん、JavaだろうがVBだろうがRPGだろうができますけどね。

これを数時間で終わらしてしまうのが標準になったら、億を超えるプロジェクトはほとんどなくなりますからね。それに気づいて拒否しているならその戦略は認めます。（普通、気づいていたら自分だけはできるようになると思うけどね）

変えるには、今の不況を利用して、お客さんを巻き込んで再教育とそれに参加しない人を淘汰することができれば良いのですが。

その前に私が淘汰される可能性の方が遙かに高いので、どうしようもないですね（笑）

>これを数時間で終わらしてしまうのが標準になったら、億を超えるプロジェクトはほとんどなくなりますからね。それに気づいて拒否しているならその戦略は認めます。（普通、気づいていたら自分だけはできるようになると思うけどね）

この部分を読んで閃いたのですが、人月単価で効率が悪いほど儲かるのが問題なので、逆に速ければ速いほど単価が上がるように常識を変えるのは如何でしょうか？
※もちろん速ければ言いというものでもなく、実行速度などを品質基準に加えるのが前提です。
億単位なのが悪いのではなく、本当に悪いのは粗悪品を億単位で売る行為です。
それならば、本当に出来る大企業は回転率が高まり儲かるので拒否する理由は無く、諸手で賛成するはずでし、 逆に反対するのならば「本当は自分では何も出来ない」事を露呈させる事になります。
是非これをお客様に教えていただきたいです。

当たり前ですけれど、中間層は人月で請けることが多いのですが、一次請けの保守・コンサル以外は人月ではなく一括で請けています。

だから、自分達だけでもできるようになれば、しばらくはとんでもない競争力を持つことになります。
その後、ディスカウント合戦になるでしょうけれど、ひとまずは教育費と競争力とどっちが得か考えればよいのですけどね。

分からん人には分からんでしょう。

今回のお題を見て、「人って経験とか環境でもの見方って結構違うねやっぱり」と思いました。

お題を見て、まっさきに思ったのは、SQL云々ではなく、このSQLが実際に動作するシチュエーションでした。
集合の操作という意味では、SQLでやるとどうなるの？っていうことは考えますが、実際にSQLでやれとは言わないだろうなぁ・・・と。
配賦のようなバッチシステム（ですよねタブン今回のモデル）ですと、
データ量の増加に伴う、
・プロセス多重度のコントロール
・自動運用のソリューション
・リカバリ、リスタートの仕組み
・テンポラリテーブルの容量とIO速度
・他のジョブ（プロセス）との競合
・ロックの実質的な時間
・実行中キャンセルの仕掛け
・ストプロやSQL文に対するなにがしかの変更時、影響調査などをするためのソリューショん、リソース管理。
など、さまざまな面から考えて、RDBMS上で済ませるのが嫌われるのではないかと思います。（こういった事を知らずに暗黙的にダメという人もいるでしょう）私もどちらかというと、最初は"ストプロ","ALL SQL" NGスタートで、本当に問題ないかを検討してね！？です。
バッチではなく、例えば、月末での事前予測的なシミュレーションを行うものだとした場合は「あり」かもしれません。ダーティリードで済むようなら理想的ですね。
後は、昼間からRDBMS上で、そんな何分も実行するような物は頼むからやめてー（＞＜）という人もいるでしょう（笑）。オンラインを圧迫しないでー（＞＜）とか（ｗ）

過去私が経験した上の話ですが、上流がアホだからストプロ禁止みたいなプロジェクトは皆無でした。もちろん上流や超上流を担当する技術者がSQLを知らないなんてこともざらでしたが。比較的、SQLそのものを知らない人でも、ストプロ・パラメタライズドクエリーも使い方次第では悪になるよね。つまり、使い方次第という人がほとんどだったと記憶しています。なんぼでも使って良いけど、課題はクリアしてねってことです。

当然ながら、半日で、作成テストまで完了するとは思えませんでした。
機能の実現に絞ってみるか、システム的にみるかでもかわるんじゃないでしょうか。
お題は、SQLに絞って見るってことでしたけど、テストといわれると、SQL文の世界から足を踏み出しちゃってますもんね。
性能や将来のキャパシティとかテストするとなるとね無理っぽいですね。

「愚痴」：上流よりむしろ下流の人に不満がありますね。

「DBに関する知識はもってらっしゃいますか？」
「ハイ」
「では、DBという観点でどんな事を今までやってこられましたか？」
「普通にSQL文を使っていました」
「・・・」
「DDLってご存知ですか？」
「イイエ」
「・・・」
「ACIDってご存知ですか？」
「シーン」
「・・・」
「デッドロックはどうですか？」
「聞いたことはあります」

こんな奴ばっかしじゃないか！？ 悪い上流人より、しょうもない下流人のおかげでトラブル事のほうが多いですよ実際。
生島さんくらいに頭でＳＱＬがぶんぶん回る人は、この二十数年間で２人しかみたことありませんね。

昔、RDBMSが無い時代でも、それぞれのファイルシステムやNDBにも効率の良いアクセスというのは当然のように語られ、実行されてきています。悪い意味でcobolerと言われる人たちが、DISKシステムのもっとも効率的なI/Oの入れかたから検討して、アクセッサを作ったりしていました。DISKはどうフォーマットされているから、どんなブロックで、どんな制御表をどこに（メモリかDISKか）おいて・・・とか。
逆に今のSQLの自称プロ的な連中は、DISKがどのようにフォーマットされ構成されているかすら気にしようとしません。こいつらアフォかと思うことも多々あります。
SQLが効率的かどうかは議論しても、自分の小さな担当範囲については、いろいろ考えても、そのストプロなりがシステム全体としてどのようなインパクトを持つものかを考えたり、知ろうとはしません。INDEXは作るけど、そのせいでどのような問題が起こるかは考えようとしません。こういったところは「基本もキャパシティも、何も知ろうとしていないじゃないか」と不満に思います。

現在の上流を云々するより、将来にむけてしょうもない上流人になろうとしている現在の若い人たちこそが、もっとしっかりするべき。現在の上流のひとはすぐに（数年で）消え去りますから・・・レボリューションは青年が起こすものでしょう！
もう上流人の不満言うのやめましょうよ（＞＜）見苦しいから。
見なければいいじゃない→そうです！そのとおり！

oumiさん、どうも。

個人的にも、これを最終的にSQL一本でやることは……。
たまにやるな（笑）それは洒落みたいなもので、ほとんどはストアドで分割していくつかの形に落とします。
これぐらいではループは書かないけどね。

参考書で簡単なSQLの例文はたくさん見るけど、難しいのは実務で使うことのないパズルだったりするので、実務でありそうな難易度で書いてみました。

今回の例題ではそこまで書くと終わらないので書いてないけど、オンラインに影響するテーブルにバッチ更新する構造にするのは、設計的にマズいと思う。

連動データは別のテーブルかCSVなど外部ファイルになると考えています。
他に2カラムしかない
　　　　売上明細ID, 配賦後消費税
1:1のテーブルを用意するのもありかなとは思いますが……。

だから、ロック・ダーティリードの問題は起きない前提です。

まぁ、全体で考えると、速ければ速いほどロック・ダーティリードの影響も小さいので、一発でやる方が良いのですけれど。
その辺の話も同時にできる人が増えてくれば、私もこんなにイライラはしません。

レボリューションは青年が起こすものですが、私も青年のつもり（笑）
上流と言ってる人たちも、ほとんどオバマより若い！一般社会から見たらまだまだ青二才ですよ。
もっとできるはずでしょう？

上みたいな問題は、やっぱりそれなりに業務知識がないと、業務の会話をしながら脳内コーディングしたり、戦略練ったりって所まで行くのはガキンチョにはつらい。
だから、上流の人があと一つ、当たり前の武器を持つべきだということで、そこを分業して逃げようと（あまつさえオフショアなんて…）考えるのは間違っていると言うことです。
逆に、SQLを覚えるだけで、Cobolerも、もう一度、最前線の戦士になれます。
私はCobolerを追い出すのは惜しいと思ってますが、変わる気がないなら、追い出すしかない。

結局、内部・外部って分け方になっていけば、もっといい業界になると思うし、技術者の寿命も長くなると思うのですけれど、いかがでしょう？

えっ？oumiさんとのやり取りを見て吃驚しました。
私は別に今回の件をSQLで実装するのに疑問を感じませんでした。
このレベルのSQLは現場ではよくある事です。
関西の会話のスピードで考えるのはちときついですが、実務として似たような実装は何度もしました。
今回のような状況の場合、現実的に考えるならば「締めやり直し」を考慮しなければならないので、逆に例題として手加減していると思います。
会計システムではよく締め処理やり直しの要望があるので、税処理に加えてそれをキャンセルしてもう一度処理しなくてはならないのです。
このほかにも階層型のデータ構造をSQLで実装とかありますよね？
基幹系業務システムでは結構あるんですけど・・・
他の分野ではないのかもかな？

インドリさん、ども。

書いておいてなんですけれど、これはやっぱり（丸めの単位で）3個に割るべきです。1文でできるけどそれは非効率な処理になるし、UNIONで繋いでもタダ長くなるだけだし。
似た記述が分散するのと、処理の効率化と、どちらを選ぶかは好みに近い範囲の話になるし、その辺がSQLの嫌われる点でもあるとは思います。（私も嫌だ）
いずれにしても、ループは書かないので、私の中ではSQLで実装の範囲に含まれます。

答えの方には書きましたけれど、実務的には納品書、請求書のデータが既に別テーブルにあるはずで、その中に計算済み（締め済み）の消費税額がないとおかしいです。

それを使わないでわざわざSQLで計算させているところは、実務から外れて例としては良くなかったかと、ちょっと反省したり、このぐらいになってくると一般的には語れなくなってきます。
全部書いたら、基幹システムの締め処理全部になってしまう（笑）

でも、ある程度の難易度にしないと会話のスピードっても面白くないし。

そんなことより問題は、分かっている人に更に分かってもらうか？ではなくって、分からない人にどうやって伝えるか？なのですけどね。

インドリさん

このような処理をやるときに、会話のスピードでSQLで処理できる確信がなければ工数にしても、パフォーマンスにしても、大きく変わってきますよね？
だから、SQLで処理できるという確信まで相当なスピード（会話のスピード）でできないと交渉できないと私は思っています。
数十秒の範囲で（しゃべりながら）確信がもてなかったら、つまり、メインの部分は確実に脳内コーディングを終えてパフォーマンスのあたりがついてなかったら、私もループする条件（工数・パフォーマンス）で話します。

するとパフォーマンスによっては他のバッチ処理との兼ね合いや、考慮しなければならない条件が変わってきます。

だから、上流の一瞬の判断で変わってくると。

で、SQLを選ぶと、私しかできなかったりするのよね。
ここで、社長の生島が怒り出すんですよ。

頭の中で大喧嘩ですわ。

仰る事よく分かります。私も出来ない事は無いけども一発ではなくて、テーブル構造を変えて処理をやりやすくします。
出来ない人はどうもテーブルを頭の中で弄くるのが苦手みたいです。
きっと彼らは真面目なのだと思います。
でも私は怠惰なので楽な方へと脳内で柔軟にシステム構造を変えてしまいます。
こういったプログラマの三大美徳が失われているのかもしれませんねorz
とはいえ、これは言葉で言っても伝わらないかも・・・

こればかりは、場数を踏まないと分からないのかもしれませんね。
もしかしたら、機会の少なさが上流技術者のSQL修得を阻んでいるのかもしれません。
下流にきたら嫌という程味わえるのに（笑）
実務レベルのシステムではSQLで数千行なんて当たり前。
オブジェクト指向言語の方も100万行なんて下手すれば１プロジェクトで経験できますよね（笑）
これだけ経験すれば誰でもSQLやプログラミングが出来るようになると思います。
本当に分からない人に伝えるという事は難しいですよね。
今のところ生島さんが発明したEXCELでの方法がベストですね！

テーブル変更…は、でかいプロジェクトでは面倒なので諦めることが多くて、バッチ処理なら中間テーブルって無茶苦茶嫌いなのに作ることもありますね。
対象データだけコピーすればテーブル変更と同じですから。

CREATE TABLE → INSERT → CREATE INDEX → イロイロ処理 → DROP TABLE

まぁ、そんな苦労もCobolerをSQLerに変身させると必要なくなるはず。
Cobolerなら業務知識のなさでイライラすることはないので、ゆとり世代より遙かに戦力になるし、SQLは業務知識の方が本来的には壁になるはずで、彼らは自分で壁を作ってるだけで絶対に超えられるから。

柔軟ってことなら、私なんて本当にこだわりないので、去年とあるプロジェクトで言語の指定がなかったから、エクセルマクロで納品したこともあるからね。

エクセルマクロでもAPIも叩けるんだから、そのプロジェクトではFTPでUNIXへアップロードしてDB2を叩いてた。

すると、エクセルシート（仕様書）＝プログラム（コボルのJCL）が完全一致するので良いわけです。

これが案外好評で（笑）
こだわる人は、「エクセルマクロなんて！」言うけどデスマになってたら意味ないし。

生島さん

>結局、内部・外部って分け方になっていけば、もっといい業界になると思うし、技術者の寿命も長くなると思うのですけれど、いかがでしょう？
そのとおりだと思いますね。ただ、例外はどうしてもあるかなと。例外の方が多かったりするかもですが・・
例えば、カスタムメイドの会計や決算等は、ちょっと厳しいかもしれませんね。

「ギョぇぇぇ！」な時はあるなやっぱり・・
ごっついSQLもってこられたら・・・面倒だから俺に持ってくるんじゃね＞＜とか言うなやっぱり（W
もしくは、「おれにデバッグしろって言うわけ？」・・・逃げ口上ですよ、ウン
で、こっそり眺めるわけですが・・
で、持ってこないと、「なんでみせないんだボゲ！」とか言うかな・・・最悪の上だぁ
ですので、良い意味で「ギョぇぇぇ！」なSQLを書いてくれる人が増えるのは良い事ですね。

インドリさん
>基幹系業務システムでは結構あるんですけど・・・
>他の分野ではないのかもかな？
分野というより、量なんだと思います。見直してみるとお題では、200万行くらいとされていますが、ついつい、その前提をすっ飛ばして、4000万～5憶の桁で考えていました。
200万だと３分どころか、40secくらいで終わるのではないでしょうか。このレベルですとインドリさんのおっしゃる通りですね。
（というこれにしても暗黙のハード基準ってのが自分の中にあるのですけど。）
共通のモデルで話をすることのなんと難しいことか・・・いやわかっています、自分がトンマだったってことは。
逆に、大量な場合でも、普通でしょと言われたら・・・「ギョぇぇぇ！」

そう言えばデスマ。
デスマなシステム（当時私の配下には内外合わせて160名程いました）全体ではこの何倍もいたわけですが、私が経験したデスマなシステムはこれ１つだけ。この時もそうですし、世間の記事などでもそうですが、アーキテクチャな問題でデスマになるってのは、あるのかな？ちょっと記憶にないですね。デスマになるシステムって、「決める人（決定権の保持者）」の問題でしかないような気がします・・もっとも「決定」という事も粒度はさまざまだったりしますが・・
「エクセルマクロなんて！」いいじゃないですか（Ｗ）エクセルマクロは、Ｅｘｃｅｌに特化した超高級(恒久)言語ですよっ！見た目はVBですけど・・・CだのC++だのできのわるい汎用言語よりよっぽどいいかと（Ｗ）

>私が経験したデスマなシステムはこれ１つだけ

一つだけ、一つだけ・・・
う、羨ましい（笑）
私の場合はデスマーチ率99.9％ぐらいです。
しかも上がアホで、エンドユーザーから要望を聞く事すら出来なくて・・・

元請け「何で仕上がっていないんだ！」
私「それは、何度も申し上げたように、○○の仕様が定まっていないからです。
この仕様は明らかにエンドユーザーに聞かないと分かりません。
以前貴方様が聞いてくるといっていましたが・・・
」
元請け「証拠はあるか！」
私「証拠ならば議事録とメールにあります。」
元請け「俺が覚えていないのはお前のせいだ！金をやっているんだから兎に角やれ。」
私「入金の方はまだですが・・・それに、何度も申し上げているように、システムの使用がお客様の判断に依存する場所なので一言お客様に聞いていただけれ場解決する問題です。もしよろしければ私が直接聞きましょうか？」
元請け「駄目に決まっている。そんなことしたらうちの存在意義がなくなるじゃないか。」
私（元からないけど。搾取するならばせめてお客様から要望を聞くぐらいの仕事はして欲しいな。）

なんていうか・・・「ギョぇぇぇ！」で、そして、健康に気をつけてくださいとしか言いようが・・・

そういった現状を正すためにも！
上下、内外関係なく、基本的な素養(SQL・RDBMS)は必要だってことですねっ！
（なんかまとまった！）

oumiさんども。

デスマーチになるかどうかは、その見積が正しいかどうかと、正しい見積が通るかの問題であって、ヘボいやり方でデスマーチになったプロジェクトだったとしても、「倍の見積（納期・金額）が通るならデスマーチにはなってなかった」ってことになります。

「倍の見積を通す力」が正しいか、「半分の見積でできる技術力」かと言われれば、技術者の私は技術力を取ってきたわけです。
それを社長の私はいつも怒っています。
自己矛盾です。

でも、不況になって技術を取って来なかった人は……。

半日でできる人が集まって普通の見積が通っていれば、全員定時退社しても前倒しで終わらせて、まだ、うなるほど利益出せます。

でね、私が異常な天才じゃないのよ。
弊社のガキンチョでもできますから、普通のSEなら、多分、1日みっちりセミナーをしたらできるようになるはず。

ただね、ガキンチョはSQLは理解できても、締め処理の意味が理解できないのよ。

私の苦悩は続くorz

パフォーマンスについては、マシンスペックもあるから単純なSQLを実測するしかないでしょうね。
ノートパソコンでやるわけないし。

>ただね、ガキンチョはSQLは理解できても、締め処理の意味が理解できないのよ。

締め処理がわからない人が居る・・・う～んまた難問が・・・
この意味を分かってもらう為にもやっぱり業務プログラマは「簿記の知識は必須」だと思います。
3級レベルなら簡単に修得してもらえるはずです。
これはゲームプログラマにとって数学が必須なのと同じかな？

クレジットカードも、携帯代も締め処理があるのに、普通に生活してたら、普通に分からない人はいるものですね。

私も自然対数の底がでてこなかったしそんなものかな。