>　わたしとしては、処理の順番のとおりFROM句から書く文法にしておけば（LINQに近いかな）これほどまでに違和感はなかったように思うのですけれど。

同感です。
確か詳解SQL1999リレーショナル言語詳解あたりでジム・メルトンもその事について言及していたと思います。
（※もしかしてプログラマのためのSQLの方だったかも？
SQL関係の本沢山読んでいるので間違っているかもしれません。）
それにオブジェクト指向もSQLも集合理論で説明できますので、生島さんが仰るとおりで設計こそ一番の問題点だと思います。

演習問題試してみました。

この間あの記事が出た直後、
各プロジェクトのリーダさん達が集まる会議があったので、終了後、結構口が達者で中身の薄い感じだった（という記憶のある）Ｒ君に、演習問題を見せて、これってどれくらいで解決できる～？　

なんて聞いてみたところ、

ちょっと眺めて
「１５分か２０分くらいかなぁ。でもoumiさん、これ１発SQLじゃたぶんだめっすよ、最低２発に分けたほうがいんじゃないかな、見た感じだと・・・」

自分「え～、テストやら量やら、顧客調整やら考えたら３日くらいかからん？」

「そんな、個別条件いれたら、なんとでもいえるじゃないですかー、oumiさん某会計システム意識しすぎ・・・っていうか、ここに２００万って書いてるし」

自分「きょと～ん、そらそうだねー、いやぁ、そんな本気でやらなくていんだわ、ありがとー」

男子三日会わざれば刮目して見よ・・・だなぁなんて反省しました（＾＾；

おお、2発に分けるというのは、ハッタリじゃなくきっちり意味を分かってますね。
（明細単位は無視していいと考えたね）

> ここに２００万って書いてるし

ってのはちょっと分からないけれど……。
まともな答えが返ってきたことがないのでうれしいです。

そのプロジェクトで、どんな資料があがってくるのか見てみたいです。

saki1208です。

うちでは、「SIGN」や「OLAP関数」使うと基本的に怒られます。
# 意味がわからないらしいです。
# 無視して使いますけど。

でも、ODP経由だとSQLの解釈が違ってたりしてうまく動かないことが...

SIGNはひどいな～。
COBOLにも関数じゃないけれどあるでしょう。
三角関数(SIN)と間違ってたりして。

> 「OLAP関数」使うと基本的に怒られます。

これはそうでしょうね。
私が強権発動しても、簡単には治まらないですから、根強い抵抗感があるのでしょう。

> でも、ODP経由だとSQLの解釈が違ってたりしてうまく動かないことが...

そうなんですね。
Express版では？RANK()とDENSE_RANK()がなぜか同じになる。
Order By の最後にユニークキーを入れたら解決しますけど。

まだまだ、バグがあるようですが、使う人が少ないとデバッグも進まないのではないかな。

生島　様

はじめまして

問題を拝見しました。うーん、できませんでした。
答えみたらなるほど。。orz

いい刺激になりました。もう少しがんばってみます。
結構、3x歳なので別の仕事に変えたほうがいいのかな(はぁ。。)

問題のレベル高いですね。（私の能力が低すぎるからかな？）
原価計算での顧客特有な処理が入った固定費配賦を思い出しました・・・。
それよりは比べ物にならないくらい楽ですが・・・思い出したのでまた鬱になりそうだ・・・

うちもSIGNは「状況によって」禁止してあります。

Oracleに限定しますが、DECODEでSIGNとか・・・
（っていうかDECODEやめようよって言うのは別のお話＾＾；）
あとは、数値の大なり小なり比較でSIGNを使う画期的な方もちょっと・・・

くまさん、ども。

答えみて、「なるほど」って思っていただけるなら十分じゃないですかね。

できるできないよりも、問題を見た（顧客から話が出た）瞬間にSQLでやるかループするかの選択をしているはずです。つまり、最初の打ち合わせでできた印象を崩せず、たとえその場に私がいたとしても、多数決で負ける可能性が高い。

上の問題なら、たぶん、そこそこの会社でも月締めならSQLなら数十秒です。
直接的な経験はないですが、年商2000億程度の上場企業でしたが、似た処理で30秒ぐらいで終わっていました。
締め処理なら数分はたいてい待ってくれますからね。

ループの選択すると、夜間バッチを選ぶことになるでしょう。

リランを考えても、同じことを繰り返せばシステムの根幹が変わってきます。

ですから、私は打ち合わせの席で無条件に夜間バッチが選択されると困るので、「オンラインでできます」って周りが反応する前にゲリラを仕掛けます。

周りはドン引きですけど……。

それがゲリラとみなされないようになって欲しいなと思っています。

あ、

> DECODEでSIGN

は確かに禁止（笑）

固定費の配賦。
これもいくつかのSQLで大抵できると思います。
個別の事情が入りすぎるので、ブログで解説できるのはこれが限界と思う。

商社の為替の差損益の仕訳というのをやりました。元は数万ステップになっていましたけど、まぁ、10個前後のSQLを組み合わせることで出来ました。
（訳あって動いてない……）

問題拝見しました。

なぜ単価が明細にあるのか、消費税率が商品マスタにあるのか。
これらの解を紐解いていく作業こそ業務の本質を表現した概念モデル＝基本設計と考えます。
SQLを使って取得するビューは概念モデルのスナップショットでしかない。
そのため、基本設計≒SQLとはやっぱりならないと思いますね。

> なぜ単価が明細にあるのか、消費税率が商品マスタにあるのか。
> これらの解を紐解いていく作業こそ業務の本質を表現した概念モデル＝基本設計と考えます。

ですね。
　　　　概念設計
　　　　基本設計 ≒ SQL
としてもいいかもしれません。

問題は、凡化しながら、細部にこだわって作っています。
細部の思いをご理解いただいて幸いです。

個人的に消費税は、かなりの確立で日常品や食料と贅沢品で税率が変わるでしょう。だから、食品メーカーとしていたり……。

「個人的に」がおかしいですね。
「個人的に……変わると予想しています」

です。