待っていました！今回も面白いです。
確かに外部設計をしないでテーブルを組むと、パフォーマンス向上のための非正規化も出来ませんし、他の事も出来ません。
私も同様の事を考えてシステムを作っています。
おまけにテーブルの変更はプログラムに多大な影響を与えます。
という事で私もあまり脳内には常にありますが早期にテーブルを確定はしません。
こういった問題は、オブジェクト指向設計がちゃんと出来ていない事に起因すると私は思います。
本来オブジェクト指向では、分析と設計が終わるまで「実装面を意識しては駄目」なので、正しくオブジェクト指向していれば後戻りも少ないはずです。
こういうとよく「オブジェクト指向だからリレーショナルとは関係ない」と言われるのですが、OMTでは集合理論もサポートしており、テーブル設計にも使用できるんですよね。
アジャイル開発についてですが、3層システムにしてSQL依存部分を最小限にすれば可能です。
それに加えて、Viewとストアドプロシージャを使いこなせばより迅速に開発できます。
この手法を使えば一人で基幹系業務システムが3ヶ月～6ヶ月で作れたりします。
ただし一人ではデスマーチ確定なので、熟練の職人数人集めるのがベストだと思います。
日本は未だに大人数開発しか頭に無く、下請けへ放り投げ続けていますが、システム開発は少人数の方が効率がいいですよね。
日本は何時まで非効率的な多重下請け構造を続けるのやら（笑）

GUIとテーブル設計を、それぞれ得意な人に任せて
同時進行させるという話もできないでもないとも思います。

MVCとかいって、それぞれ仕事を振り分けるって話もありますしね。

インドリさん

ありがとうございます。

フリーで一人でできる規模の案件では、基本設計の段階では資料捏造して（どうせ変わるし）インドリさんと同じように脳内で粗いテーブル設計はやって最後に確定してということも多かったです。
（少ないけど）本当にオブジェクト指向もSQLも理解している人は、いろんな亜流があると思いますけれど、多分、似たようなやり方をするでしょう。

一人では無理でも、電話から、議事録作成などの秘書的な人がいたら、少々のシステムは組めますね。

大きな規模になったとき、新人も育てつつ、業務知識のあるベテランに戦力になってもらうにはと考えたのが記事の内容で、フリーではどうしようもなかったから起業しました。
しかし、ベテランが言うこときかないのですよ。
そりゃ、意地もプライドもあるでしょうが困ったものです。
その上、Javaなどの言語にロジックを書いてきた人たちは、既得権を離したくないという抵抗も受けてなかなか進みません。

不況になったお陰で、本当に生産性を考え出せば、変わってくるかなと思っているのですけれど。

ちょっと宣伝。
弊社は、.Net で開発することが多いのですが（Javaは持ち帰り案件が少なくって、手を出しにくいです）いつまで経っても1行複数明細表示が簡単にできないのにイライラして、グリッドコントロールを作りました。
よろしかったら試してみてください。（弊社はメーカで、アセンディアが販社です）
http://www.ascendia.jp/persimmon/products_pages/flg_pages/

turboさん。ども。

MVCで言えば、Mの部分がストアドプロシージャにあたります。
別に斬新でもないけれど、一般的に M の部分を作るのにテーブルが必要だからと、他が固まらないうちにテーブル設計をしてしまっているのが問題だとお話しているわけです。

VCを先行させるには、MのスタブをJavaなどで作るのと、私の言うエクセルでダミーのストアドを作るのとを比べると、Javaなどで作るのはロスが大きすぎます。

JavaでCobolのように設計・コーディングしてたらイライラしませんか？
不満は溜まりませんか？
単純なSQLで何とかしようと思う考え方は、SQLを良く知っているものからすると、同じようにイライラするのです。

言語も人も、得意な分野に効率的に割り振るべきです。

生島さんお返事有難うございます。
今ちょっと思いついたことがありますので参考になればと思い書きます。
熟練の頑固職人を説得するには、向こうの言葉や概念に合わしてしまえばいいと思います。
私は無差別に手を出しているので言語マスターの気持ちも分かります。
私にも頑固親父の側面があるのです。
彼らはSQL言語という所と集合理論に抵抗を感じているのです。
彼らは腕に自身がありますから、JavaやC++などの言語の能力も絶対の自信を持っておりますし、実際に大概のシステム作ってしまいます。
それに加えて、人間誰しも「新しいものを覚えられないのではないか？」という不安を持っていますので、彼らに新しい事をしろと直接的表現で言ってしまうのは逆効果だと思います。
そういった職人の方々は、集合理論なんていわれたら抵抗感を露にしますが、「データ構造は仕様変更が多いから最後に決めよう」とか
「テストファーストで組みたいからインタフェースを先ず定義して、内部ロジックは後で実装しよう！」いった馴染みのある表現に変えたら、（全うな人は）自分のプログラム品質を上げるためならば喜んで受け入れると思います。
ポイントは、「何だ今までと同じか。用語が違うだけなんだ！」と思わす事です。
※実際に彼らは自分流に集合理論を修得してしまっているようです。
私は自分自身をそうやって催眠にかけて、情報処理技術全般を無差別かつ抵抗感無く学べましたので効果あると思います。
何の分野も共通事項があるので、そこを突破口にするといいと思います。
少しでも参考になれば幸いです。
私もこの業界の構造に疑問を持っていますので生島さんを応援しています。

>http://www.ascendia.jp/persimmon/products_pages/flg_pages/

すばらしいグリッドコントロールですね。
早速使ってみます。

インドリさん。どうも。

> 彼らは腕に自身がありますから、JavaやC++などの言語の能力も絶対の自信を
> 持っておりますし、実際に大概のシステム作ってしまいます。

もう少しレベルが低い人を対象にしているかも（笑）
大阪人特有のせっかち（イラチ）な性格なので無理を言いすぎかもしれません。

確かに、集合理論が難しいのかもしれません。
次に書こうかと思っていたのですけれど、SQLを魔法か何かと勘違いしている人が多くいるのが問題と思っていました。

DBエンジンはC++（かJava？）で作られているわけです。
つまり、C++で既に出来上がっているものを、JavaやC++で、もう一度書くのが無駄だと言ってるんですけどね。

私は、
　　基本設計 ＝ SQL
　　詳細設計 ＝ 実行計画
って説明しているのですけれど、これが余計に分かりにくいのかな…。
SQLってもともと、基本設計を直訳すればできるように設計されていて、だからこそ、分岐もループもない言語なのですけれど…。

基本設計 ＝ SQL だから、会話のペースで直訳できるし（まぁ、アルゴリズムでも会話のペースでできますけど）SQL は上流に向くと私は考えています。

アルゴリズムが分からないとチューニングできないのですから、アルゴリズムが判ることは無駄じゃないし、SQL は簡単になっているはずなのですけどね。

「SQLで！」と言うと、オブジェクト指向が分かってないとか言われたりしますけど、私も（弊社も）SQLから、WEB、SEO、コンポーネント、制御系まで、無差別に手を出しています。
何でも喰いつくのでブルーギルと呼ばれている（笑）
経営者としてはかなり？です。

少なくとも、オブジェクト指向が分かってなかったらコンポーネントには手を出さないはずですけどね。

宣伝させていただきましたが、グリッドは、今、マイナーバージョンアップを控えていますので、もう少し後にお願いします。

えーと、私は生島さんの考えは別に否定はしていませんが、絶対だとも思っていません。

だから、議論が必要になる場合があるわけですが、生島さんの事情がよくわかりませんから、あまり突っ込んだ意見を出すことはできないのです。

SQLの方がいいならSQLでやってしまえばいいですし、JavaでやるならJava、あるいはCOBOLでと少し柔軟に考えたいです。

おっしゃる通り、GUIはアジャイル開発がやりやすいとはいえ、GUIもテーブル設計も開発スキルが低くていいわけではありません。いきなり「SQLのチューニングが簡単」と言われてもSQLの経験がない人にはわかりません。

たとえば、GUI開発は任せてもらっても構わないのですが、テーブル設計は他人にお願いして欲しいという意見を部下が言ってきたら、どうしますか？

> たとえば、GUI開発は任せてもらっても構わないのですが、テーブル設計は
> 他人にお願いして欲しいという意見を部下が言ってきたら、どうしますか？

そうした方が良いと書いているのですが…。
GUIの開発担当は、テーブル設計を無視して良いということです。
スキルの指向を「Javaなどの言語」「SQL（テーブル設計）」と2方向にしないと、両方を高いレベルでできる人しかまっとうなシステムが組めなくなる。
それには、言語の特性の違いが大きすぎて、現実的ではないでしょう。
だから、反発も起きるのです。

同じ人がやったとしても、工程として切る方がいい。
問題は「SQLが高いレベルで分かる」という技術者が圧倒的に少ないということで、前振りも書かせてもらいました。

技術者が特定の技術（SQL）を避けて、結果、工数は数倍～十倍、パフォーマンスは十倍～百倍のシステムを納品しているわけです。
その現実がおかしいと考えています。
Javaでやった方が簡単と言う人も多いですが、前のエントリーの内容をJavaのどんな達人を連れてきても30分ではできませんから。「SQLが高いレベルで分かる」人にとっては、SQLの方が簡単となってしまいます。

メンテできないと言うのも、良く聞くいいわけですけれど、それも、「SQLが高いレベルで分かる」という技術者が圧倒的に少ないという技術者側の問題で、客に堂々と言ったら、プロとしてはかなり恥ずかしいと思います。

記事を読むと、UI層が直接DBアクセスを行うように読めますが、DBの物理設計を実装と切り離したいのであれば、UI層がDBアクセスを行わないような設計にするのが良いと思います。UI層の実装手段としてのスタブのストアードプロシージャを作るのではなく、スタブクラスを作るのです。
それから、「テーブル設計」というのが具体的に何を指しているのか今一わかりませんでした。物理設計のことでしょうか。物理設計をUI層と切り離すのは良いと思いますが、それでもデータ層の分析・論理設計（あるいは概念設計とも呼ばれる）は先に行うべきです。

データにアクセスするのはストアドプロシージャです。

UI層の後に、もう一層加えても良いけれど、おそらく無駄です。
スタブクラスを作るのも、非常に無駄です。

本文にもあるとおり、概念設計は同時に行います。どんなドキュメントにするかはプロジェクトの考え方だと思いますが、SQLが高いレベルで分かっていれば、議事録程度で充分ですけれど…。

Javaなどの言語で、ロジックを書かなければ既得権を奪われる層が多いのは事実ですけれど、そんな固定した考え方では業界としても、個人としても成長がないのでは？特定の分野を嫌いすぎです。

>UI層の後に、もう一層加えても良いけれど、おそらく無駄です。
そうでしょうか。UI層で直接DBアクセスを行うと、凝集度は低下しますしテスタビリティも低下します。

>スタブクラスを作るのも、非常に無駄です。
ストアードプロシージャなら良くて、スタブクラスだと「非常に」無駄となるロジックがわかりません。

>本文にもあるとおり、概念設計は同時に行います。
記事では、どの程度の規模のチームを想定しているのか良く分からなかったのですが、誰が何と同時に行うのでしょうか。

>Javaなどの言語で、ロジックを書かなければ既得権を奪われる層が多いのは事実ですけれど、そんな固定した考え方では業界としても、個人としても成長がないのでは？特定の分野を嫌いすぎです。
これは私宛のコメントでしょうか。だとすると、なぜこのようなことを言われるのか分かりません。

返信内容を読むに、私が思った以上に酷い状況みたいですね。
私自身が会話と共に、頭の中でオブジェクト（データとプロセス）が中間言語として浮かび、それを元にSQLはもとより大概の言語に翻訳出力できるのでそれほど言語ってものを意識しておりませんでした。
SQLってそんなに人口が少ないとは知らなかったです。
それ程難しい言語ではないのに・・・

>DBエンジンはC++（かJava？）で作られているわけです。
自分で簡単なRDBMS作った事があるので、言いたい事よく分かります。
DBって、昔は独自データファイルで済ましていたものをより高度にしたものなんですよね。

>「SQLで！」と言うと、オブジェクト指向が分かってないとか言われたりしますけど、
オブジェクト指向を表面的にしか知らない人がよく言う台詞ですね。
オブジェクト指向はデータ＋プロセスなので、データを無視してよい理由はありません。
生島さんがどのような気持ちで【「みんなが言ってる」は技術者が口にする言葉じゃない！】を書いたのか伝わってきました。

でもそれ程心配しなくてもいいのかもしれません。
Windows開発で主流の.NETではLINQも登場していますので、SQLへの接点が多くなっており、最新機能が分かる人はSQLも分かるはずです。
これからはO/Rマッピング解消の時代なので、もっと埋め込みSQLが進化するでしょう。
DataTableとかどうみてもオブジェクト指向で表現したインメモリデータベースですし、XMLデータベースにしてもリレーショナル理論で考えられます。
※本当は階層型に近い
もし何も学習しない人がいる場合は、それはもう別次元の問題だという気がします。

本文の例でいくと、Javaなどの言語からストアドプロシージャへのアクセスは、

"exec Test " + 入力値;
または、
"exec Test ?";
Pra(0).Value = 入力値;

だけです。（ここが本文に抜けていてすみません）

完全に分離できていますから完全に分離してテストできます。
ストアドプロシージャのスタブならエクセルで5分で作れます。
5分で作ったものですから捨てても惜しくないし、変更も5分以内にできる。
しかし、私にはスタブクラスが5分では作れません。
（スタブチームに依頼とか…ってプロジェクトもあったけど）

スタブを本番用に書き換えるのは、SQLが高いレベルでできる人がやれば、非常に効率的です。
できない人がやれば、非常に効率は悪いです（というかできない人なのですから不可能です）メンテもできません。

SQLができない人のことを考えると「UIに集中してください」
となります。

UIも得意としてない人のことを考えると「何れかを習得してください」
となります。

SQLが難しいから習得できないという前提で考えるか、SQLは簡単で習得すべきと考えるかの問題では？

インドリさん

「前振り」まで完璧にご理解いただけると方がいるとは（笑）感謝感謝。

> >DBエンジンはC++（かJava？）で作られているわけです。
> 自分で簡単なRDBMS作った事があるので、言いたい事よく分かります。

そういうことなんです。
私は DOS版のLotus 1-2-3 のVLookupとマクロを駆使して作ってましたからね。
再計算に何分も掛かったり（苦笑）

SQLを知ったときには「まさに自分で作りたかったものだ！」って…。
そういう感覚がもてない世代は、ある意味不幸かもしれませんね（オヤジだ…）

>そういう感覚がもてない世代は、ある意味不幸かもしれませんね（オヤジだ…）

話しが少しずれてしまうかもしれませんが、もしずれたら大目に見てください。
生島さんの言葉で思い出したのですが、世代と言えば以前熟練の方に聞く所によると、今時の人の多くはアルゴリズムとデータ構造すら学習しないで、開発ツールでペッタンコするだけしか知らないらしいです。
さらに、技術者なのに技術にまったく興味がなく質問すらしないそうです。
そういった非プロな精神状態もこの問題の根底にあるのかもしれませんね。
何時からそんな風になってしまったのでしょう。
私は30歳なのでそれ未満の20代の世代かな？
もしかしたらSQLだけではなくて、情報処理技術そのものが軽視されているのかもしれませんね。

アルゴリズムしかり、データ構造しかり、業務知識しかりです。
本気で取り組んだら面白い仕事だと思うのですけれど…。

脱線です。

デスマとか、3Kとか、後ろ向きの情報が、学生などのこれから業界に入ってくる人、入りたての人にいきわたり過ぎていて、誤解（？）からスタートしているんじゃないかと思う。
デスマを起こさないことが上に立つ人間の責任なので、社長としては大きな声では言えないことですが…。下の立場でそこに巻き込まれたときに得るものもあるのです。

ところが、実際にデスマになったとき
　　「来た来た、これがデスマか。（権利を）主張して逃げないと大変なことに…」
って考えて、最初から逃げ腰になっているように見えます（見えるというかおそらくビンゴです）

逃げ腰でも、結局、巻き込まれるのですけれど、何も分かってないうちから「関わったら損」と逃げ腰に考えていては得られるものはありません。
消耗して、悲劇のヒーロー・ヒロインを気取って終わりです。

デスマに入ったら、そこで肉体的な苦痛から逃れるのではなく、技術的に回避策を苦悩して考えていれば、辛かったけど「いろんなものを得た」となるわけです。
それが、私の血肉になっている。

誰もやってない分野は、何が起こるか分からないので、運次第でデスマは避けにくい。
しかし、誰もやってない分野の知識と経験を得られるわけです。

人材を割り振る立場として、問題のない（経験のある分野で、予算・納期が十分にある）プロジェクトに力のある人材を入れると、本文の様な余計なことに口出しして来てうるさいので（笑）
力のある人間ほど、基本的に問題のないプロジェクトには呼びません。

力のある本人も、仕事を選べたとしても、分かりきったものを避けて、新しいことが出来るプロジェクト（デスマの可能性大）を選ぶ傾向にあるから、力のある人ばかり、更に力を蓄積してしまう。

能力も格差社会ですね。

立場上、書きにくいので記事にはしないけど（笑）

生島さま、はじめましてNEOと申します。

私は「DB＆SQL大好き人間」であり、「最高のテーブル設計とシンプルなSQL」こそが、
.NET系でもJavaでも何でも全体のコーディング量を圧倒的に減らせると考えていて、
実際に数々の複雑な画面や機能を、可能な限りシンプルな実装で、不具合等もほぼ無く、
安定したリリースを続けていると自負しています。

さて、「テーブル設計は実装の後に！」というのは少し誤解を与える気がします。
補足するなら「テーブル設計の"完成"は実装の後に！」。設計は実装と平行で、
執筆上の仮ストアドプロシージャの作成＝項目を考える時点でテーブル設計の一部。

また私は「仮ストアドプロシージャを修正しながら実装を終えた段階で設計完了」と、
「Createした実テーブルやView含めて修正しながら実装を終えた段階で設計完了」とは、
大して差が無いと思いますし、むしろテストデータの登録や更新処理の実装も考えれば
後者の工数の方が軽いと思っているので、この執筆で言いたいことは、実テーブルを
いつCreateするかは関係無くて、「テーブル設計は、実装中にも柔軟に変更せよ」という
ことを、一番訴えたいのかと思いますが、いかがでしょうか。それは非常に同感です。

また、本来は「画面の表示／入力項目」と「業務ロジック」が決まれば、
実装前に全体のテーブル構造やテーブル設計は決まるはずです。

実装前にこの「設計」の完成度が高いほど、実装中にそれらを考える余計な思考時間を
大幅に減らせると共に、基本的な部分の勘違い・漏れ・手戻り等も減らせます。
設計は、複数人数で開発している場合や、画面とバッチ間などの情報共有にもなります。

またもちろん、実装中に気づくテーブル設計の間違いや不足項目もあると思うので、
その時は柔軟に、テーブル設計を変えて定義変更すればよいだけです。
本番リリース前のテーブル定義変更は、早めに見つかれば大した工数ではないはず。

私も、１度決めたテーブル設計を変えずに無理な実装を続けることは、最終的な工数や
トラブルにつながるだけだと思っているので、新規開発では絶えず設計を改善します。
但し、既存システムに大きく影響を与える場合などは、妥協案等が必要な時はあります。

また、「非正規化」はパフォーマンス向上の為に従来は必須の設計でしたが、その分、
"非正規化するための処理の開発、非同期のデータの考慮、１日遅れの値"、など、
課題も有り、今のＤＢ＆サーバ性能であれば、教科書通りに「正規化」してそのまま抽出
することが、低工数で済む事も増えています。もちろん「必要な非正規化」もありますが、
これらもやはり実装の段階で気づく事ではなく、UI等が決まった時点で設計できる事です。

ということで私は結局「いかに実装する前に完成度の高い設計ができるか」という事と、
「それでも実装中に問題が発覚したら、柔軟に設計を改善せよ」という事が、重要と
考えます。私はいつも"設計段階に相当残業し、実装段階以降は稼動後含めて平穏"主義。
私にとって「設計力無しでいかに高品質なシステムを作るか」の回答は「無理」ですかね。。

以上、長文すみませんでした☆

NEOさん
こんにちは。

> また私は「仮ストアドプロシージャを修正しながら実装を終えた段階で設計完了」と、
……
> いつCreateするかは関係無くて、「テーブル設計は、実装中にも柔軟に変更せよ」という
> ことを、一番訴えたいのかと思いますが、いかがでしょうか。それは非常に同感です。

おっしゃるとおりですけれど、中途半端に「逃げ」を作らないように極端に言わないと、文化が違う人たちには「逃げ」ばかりが目に付くだろうと。
もちろん、私が一人で作るときは本文にあるような面倒なことは…テーブル変わっても平気なところは先に作るし、ダミーデータも突っ込むし。
その頃合が分かるのは、経験をいくつか積まないと無理です。

正規化と非正規化が良い例で、正規化と言いながら、同時に非正規化を言うから、にわか技術者には訳が分からなくなる。と言えば分かってもらえますよね。

まず、正規化が判らない人に、非正規化を教えるわけにはいかないわけです。

小さなシステムを取って確実に稼ぐのもいいけれど、大手で無意味なデスマに苦しんでいる技術者を解放してあげたいと考えています。

でも、意外なことにデスマに苦しんでいる技術者からも反発を食らうのです。
彼らは、デスマか？SQLを習得するか？と言われれば、デスマなのです。

そこまで嫌わなくてもいいと思うのですけれどね。

> Javaなどの言語で、ロジックを書かなければ既得権を奪われる層が多いのは事実ですけれど、そんな固定した考え方では業界としても、個人としても成長がないのでは？

全く同じことがSQLに関しても言えるという、そんな話があります。

以前、SQLは得意だけどJavaは苦手という人にちょっとしたツール(Java+簡単なSQLでやれば30分で終わる程度のもの)を頼んだところ、SQL側でできるだけ解決してJava側の実装を抑えようとした挙げ句、一日経っても終わらなかったということがありました。
どうも、俗に言う「金槌を持つと全てが釘に見える」状態に陥っていたようです。
SQLに自信を持つのはいいんですが、もう少しバランスの取れた判断をしてくれと思いましたね。
SQLが向かない領域というのも厳然として存在するわけですから。

> 以前、SQLは得意だけどJavaは苦手という人にちょっとしたツール(Java+簡単
> なSQLでやれば30分で終わる程度のもの)を頼んだところ、SQL側でできるだけ
> 解決してJava側の実装を抑えようとした挙げ句、一日経っても終わらなかった
> ということがありました。

具体的な例ではないので良く分かりませんけれど、バランスはしているつもりですよ。
よろしかったら、弊社の製品も見てください。

http://g1sys.co.jp/gurutto_plus/
http://www.g1sys.co.jp/grid/

どちらも、単純にSQLだけにこだわっていてバランスしていなければ出来ないと思います。
少なくとも、オブジェクト指向が分かってなくってグリッドコントロールを作れるでしょうか？

もちろん、SQLにこだわった製品もあるけれど…。
http://www.g1sys.co.jp/sakutto/

ちなみに、弊社は10人に満たない会社です。

弊社は、Cobol以外なら大抵のことはやりますし、オブジェクト指向も、SQLも、十二分に理解しているつもりです。その上でRDBMSを使うシステムにおいては（できない人の反発を抑えられたら）SQLにロジックを寄せた方が効率的と考えています。

正しい答えなど存在しないから建設的な議論をしたいです。
私は出せる範囲で具体例を出しているつもりですので、是非、具体例を示していただいたり、具体的に私の論のおかしい箇所を御指摘いただければと思います。

尚、「理解できる人が少ない」「SQLを嫌う人が多い」という問題点は現実的に、体感的に理解しております。

同時に、経営者が短期的な利益を見て反対するならともかく、技術者なら、好き嫌いで言語や手法を選ぶのではなく、論理的にポテンシャルを検討して選択すべきと考えています。

もし、今回、前回の内容を方法論として深めていくのであれば、まずやるべきは適用可能な領域を定義することではないでしょうか。
ここまでの議論を見た限りでは、かなり限定された領域(SQLでロジックの大部分が書ける)にしか適用できないように思います。
ですから、まずは適用できるかどうかの判定方法をある程度定式化して提示されてみてはいかがですか？

これまでのところ、生島さんと似たような仕事をされている方は賛成、そうでない方は疑問を呈するという単純なパターンが続いていますが、これも適用領域が示されていないからではないかと思います。

> これまでのところ、生島さんと似たような仕事をされている方は賛成、
> そうでない方は疑問を呈するという単純なパターンが続いていますが、
> これも適用領域が示されていないからではないかと思います。

噛み合わないのは、そこだったのですね。
条件としては、
　　RDBMSを使うシステム（MySQLはちょっと機能不足ですが）
　　100万円以上の規模ですかね。
　　＃ 100万円以下では差が出ないだけで可能ですけれど。

弊社の経験でしたら、100機能程度の中小企業の基幹システムぐらいの経験しかありませんけれど、UIを除けばSQLできない部分は汎用機などとの外部連携ぐらいですね。

それ以外は、前の
http://el.jibun.atmarkit.co.jp/g1sys/2009/01/sql-2b18.html
の例が会話のスピードでできる人なら、ほぼすべての機能をSQLで出来ますよ。

出来ないと思っている人は「出来るわけない」が前提になっているから噛み合わないのかも知れませんね。

単なる食わず嫌いだと思いますけれど。
メンテできないと言うのも、上から下までちゃんと指導していないから当たり前の話ですが、ちゃんと教育すればメンテもできるようになるでしょう。

tripod さん、追加です。

下請けですけれど、一部上場企業の為替システムのリプレイス（やり直し）Javaで出来たものをSQLに直しましたが、ソース量は機能によっては20分の1から、5分の1になりました。

このシステムは全体としては10億以上で、為替部分は一番難しいと言われていましたけれど…。
大きなシステムほど効果は大きくなります。

出来ないという自己基準を持ち出して、自分が理解できないからNGとか、メンテできないとか、邪魔する人が居なければうまくいきます。

できる人が増えれば業界が変わるんじゃないかと考えています。

たとえば、営業支援システムを作る場合、アポをシステムに記録するために予定表が必要です。当然のことですが、定期的に開催される予定を扱えないと困ります。
予定のパターンとしてはMS-Outlookにある定期的な予定と同程度のものをサポートし、祝日と重なったら翌日に振り替えたり、飛ばしたりといった指定も欲しいとします。
こうして作成された定期的な予定をカレンダー上に表示するとき、SQL+UIでどう書きますか？

CASE～WHENで長々と書けばなんとかならないこともないですが、手続き型言語で書いた方がスケーラビリティやメンテナンス性がいい、というのが現時点での私の結論です。
DBをスケールアウトするのはかなり難しい一方(最近のOracleならRACがありますが)、アプリケーションサーバを増やすのは(状態を持っていなければ)非常に簡単です。
OOPLで適切にモジュール化すれば、単体テストも一つ一つをシンプルにでき、メンテナンス性が向上します。長大なSQLは、長大なメソッドと同じ理由でメンテナンスが難しくなります。

とりあえずはこんなところですが、参考になりますでしょうか？

書き忘れたので補足。

スケールさせる必要もメンテナンスの必要もなければ、SQL+UIで実装することになんの問題もありません。

> たとえば、営業支援システムを作る場合、アポをシステムに記録するために予定表が
……
> 翌日に振り替えたり、飛ばしたりといった指定も欲しいとします。
> こうして作成された定期的な予定をカレンダー上に表示するとき、SQL+UIでどう書きますか？

いい例ですね。
ありがとうございます。

これはUIとして変更するか（変更を見せながら行う必要があるか）バッチ処理的に変更する必要があるかによって変わります。

変更したことを見せる必要があるなら、そもそもUIの要件ですね。
バッチ的に変更するならDB、UI上で変更するならUIと、要件によって外部なのか内部なのか峻別する必要があります。

SQLでしたからと言ってCASE～WHEN で長々と書かないといけないかどうかは、要件にあったテーブル構造になっているかによって違います。
パッと見た限りで、私の考えたテーブル構造とSQL文では、CASE～WHENは出ませんでした。休日マスターとトランザクションの構造によっていかようにも書けます。

ですから、テーブル設計は後回しにした方が良いわけです。

しかし、例の要件であれば、おそらく前にズラしたいときと、後にズラしたいときはユーザの都合で変わりますから、メッセージボックスなどで確認する必要があり、外部UIの要件だと思います。

他にカレンダーが必要なシステムで、工程・生産管理の山積・山崩処理なども、DB側の方が遙かに効率的です。
山崩バッチに16時間かかるシステムを見たことがあるけれど……DBではなくC++でやってました。
DBで変えた後、ユーザが独自の修正をすることになるでしょう。

スケールさせる必要はありません。

世の中にメンテナンスが必要ないシステムはありません。
メンテナンスできないのは、そもそもSQLを嫌う人が多すぎるから出来ないだけの話です。
人が居ないからメンテナンスできないというのは認識していますけれど、「技術者が好き嫌いを言うな！」というのはおかしいでしょうか？

バッチ処理というのが何を意味しているのか謎ですが、ぶっちゃけGoogle CalendarクローンをDB+UIのみで実装できるかという話で、問題にしているのは定期的な予定です。
まず、定期的な予定をDBに永続化するときに実日付に展開するか、参照時に展開するかという選択がありますが、ここでは参照時に展開するものとして考えています。
展開元のパターンとして、N日ごと、N週ごとのX曜日(複数指定可)、Nヶ月ごとのX日、Nヶ月ごとの第X Y曜日、Nヶ月ごとの月末、N年ごとのX月Y日、N年ごとのX月第Y Z曜日、N年ごとのX月の末日があります。
現実には展開した実日付の一部だけを変更したり、振り替えがあったりしてより複雑になりますが、基本はこんなところです。
これを簡単な(長大ではない)SQLで解決できるような手法が私の頭では思いつかなかったわけですが、生島さんはどういうテーブル構成とSQLで解決できるという見通しなのでしょうか？
予定表の意味が違うのかな…。

> スケールさせる必要はありません。

ここがよく分かりません。現実にパフォーマンスが問題になってから考えるということですか？
たとえば、100万ユーザーを一つのDBサーバのみで運用するのは、無茶な気がしてなりませんが。
適用範囲の話をしたときに、ユーザー数やリクエスト数ではなくてシステム構築の金額が出てきたので、どうも不安です。

> 「技術者が好き嫌いを言うな！」というのはおかしいでしょうか？

おかしいと思いますよ。
SQLを知った上で嫌いと広言しているのであれば、その技術者はSQLと関係ない世界で仕事をすればいいだけの話です。適材適所ですね。
やってみたら案外面白かった、好きになったということもあるので食わず嫌いはどうかと思いますが、好き嫌いそのものは否定しません。
もちろん発言を封じる権利は誰にもありませんから、「技術者が好き嫌いを言うな！」と言うのも自由ですけど。

> 定期的な予定をDBに永続化するときに実日付に展開するか、参照時に展開するか
> という選択がありますが、ここでは参照時に展開するものとして考えています。

参照時に展開すなら、逆に簡単なSQLで可能です。
しかし、4月は前にズラし、5月は後にズラすという要望が当然出てくるので、ここは、静的に持つべきじゃないかと思います。

表示部分はUIとのコラボレーションになるわけですが、大半がSQLでいかようにもなるでしょうね。

> ここがよく分かりません。現実にパフォーマンスが問題になってから考える
> ということですか？
> たとえば、100万ユーザーを一つのDBサーバのみで運用するのは、無茶な
> 気がしてなりませんが。
> 適用範囲の話をしたときに、ユーザー数やリクエスト数ではなくてシステム
> 構築の金額が出てきたので、どうも不安です。

これはよくある「洒落にならない」誤解です。
例えば、近々リライトして記事にしようとしていますが、こちらをとりあえずご覧ください。

http://www.g1sys.co.jp/column/_2006_11_10.html

Webシステムでもクラサバでも同じですが、APサーバ・クライアントはDBサーバの処理のほとんどを肩代わりしていないどころか、DBサーバの負荷を増やしています。

ですから、DBサーバで処理できないとしたら、そもそもDBサーバの処理能力の見積を誤っているのですけれど、APサーバやクライアントで処理したら、もっと早くにシステムとして破綻します。

> > 「技術者が好き嫌いを言うな！」というのはおかしいでしょうか？
>
> おかしいと思いますよ。
> SQLを知った上で嫌いと広言しているのであれば、その技術者はSQLと関係ない
> 世界で仕事をすればいいだけの話です。適材適所ですね。

RDBMSを使ってないなら良いと思いますけれど、少なくともあなたはRDBMS + Java（などの言語）の分野で飯を食ってるのでしょう。

RDBMSを使いながら、Java（などの言語）言語にロジックを寄せて、「SQLを使えば半分以下の工数で10倍以上のパフォーマンスを出せますが、僕は嫌いなので…」とあなたの顧客に説明できますか？

「メンテできないというのもよく聞きますけれど」開発時にそれだけ差があるなら、「メンテできる人を育てましょう」って考えるのは素人考えなのでしょうけれど、この業界以外では常識でしょう。

もっとも、現在の上流・下流という分け方になっているためです。
外部・内部の区分けになって、UI担当ですという人が、SQLは嫌いですは何の問題もないです。
しかし、上流・下流と分かれている現在は、必須のスキルだと私は訴えているわけです。

あれ？お二人が言っているUIって、お客様に見せる画面の方？
そうならば、普通SQLだけではしません。
データベースでの外部設計はまた違う意味です。
私はSQLだけで完結できるプロジェクトはほぼありえ無いと思います。
その逆に、無理して命令型言語だけを使うプロジェクトは不自然だと思いますので、システム次第だと思います。
ただ、組み込み開発などは特殊な例は別として、永続的データがあるのならばDBMSを使うものだと思います。
それが、オブジェクト指向DBMSならば別の話しだけどね。
ちなみに、予定表は何度も作りましたが、当然お客様が見る画面は問い合わせ型言語以外で画面を作ります。
それで、無論必要なデータは問い合わせ型言語でもってきます。
そうしないともってこれませんから・・・
皆そうしていると思っていましたが違うのですか？

それにしても気になるのですが、生島さんが見たSQLを忌避して使用しない技術者ってどんな人ですか？
もし、自分がSQLを使いたくないと言うだけで永続データを認めないと言うのならば、システム構築は出来ないと思います。
もし仮に全員SQLを知らない・触らない・DBMSを使用しない会社、もしくはグループと言うものがあるのならば是非知りたいです。
次の記事でその様子を書けば非常に面白いと思います。

インドリさん、ども。

カレンダー系はSQLで表現するのは苦手とする人が多い。
UIも複雑になる。
UIが複雑だからこそ、UIから作って、テーブル設計を後回しにすればメリットがあると思うのですけれどね。

> それにしても気になるのですが、生島さんが見たSQLを忌避して使用しない
> 技術者ってどんな人ですか？

これはさすがに記事にはしないけど……。

個人とか気心の知れたできる人と組んでやってると御存じないかも知れませんが、億単位のシステムでSQLでJOIN禁止とかもありましたよ。O/Rマッパーがはやった頃か。
JOINしないためにVIEWを提供しますとのことで、VIEWを作ってくださいとDBチームに申請を書くわけです（笑）
JOIN禁止は最近はさすがになくなったけど、サブクエリは普通に禁止のところがありますね。
10年やっててHAVINGを使ったことないです。っていう人もザラにいますよ。

昔、VBで配列禁止というプロジェクトもあったけど、「作れないというのか！動かないというのか！！！」って言われて議論にならなくって困った。
やり過ごして逃げるしか出来ませんでした。
どう答えたら良かったのでしょう？

今も同じ気分です。

配列禁止よりSQLの方が、工数・パフォーマンスに影響するのに、具体的に工数・パフォーマンスを出してもダメなら、諦めるしかないのですけれど、諦めきれないのです。

追加。
Oracleのコミュニティでも憤っているひともいますね。

http://otn.oracle.co.jp/forum/message.jspa?messageID=28019300

冗談抜きでJOIN禁止もありましたよ（笑）

生島さん、ども。
何でさっきあのように書いたのかといいますと、お二人とも興奮し過ぎて本題から脇にそれてしまっていると感じたからです。
第三者から見たら「JavaもSQLも要るのに何故二人は言い争っているのだろう？」と見えてしまいます。
そこで、話しを元に戻すために、「どれほど酷いのか」を生島さんに書いていただきたかったのです。
それを書いた方が建設的だと私は思うのです。

>個人とか気心の知れたできる人と組んでやってると御存じないかも知れませんが、億単位のシステムでSQLでJOIN禁止とかもありましたよ。O/Rマッパーがはやった頃か。

誤解されているようですが、私は1000万円～億単位のシステムを構築してきましたし様々な体験をしてきました。
ですから余計にSQLとJavaで言い争っているのを聞くと「両方要るよね。根源的問題はそこじゃない。」と感じてしまうのです。
そんな瑣末な事で言い争ってしまうと、タダの言語戦争と誤解されて、IT業界のおかしさが他者へ伝わらないと思います。
ですから、そこをちゃんと記事にした方が良いと私は思うのです。
そうすれば、いわゆる上流の人が如何におかしなをしているのか分かってもらえるのではないでしょうか？
今のままでは言語戦争と勘違いされてしまいます。

> ですから余計にSQLとJavaで言い争っているのを聞くと「両方要るよね。
> 根源的問題はそこじゃない。」

瑣末なことなのですけどね。

要員配置や、オフショアまで考えて書いているのですが、基本的にツッコミは瑣末な方に入るのです。

「炎上上等！」と言ってきた以上、余程のことがない限り反論せねばと思っています。

> ですから、そこをちゃんと記事にした方が良いと私は思うのです。
> そうすれば、いわゆる上流の人が如何におかしなをしているのか分かってもらえる
> のではないでしょうか？

悪口（笑い話）にしかならないような気がする。
一応、そういう人とも仕事してますし、変な名前ですが本名で書いているから逃げれないしね。
既に遅いかな……。

tripod さん

熱くなってすみません。

カレンダーの仕組みもSQLで可能です。（もちろんデータ処理ですよ）
しかし、ご指摘のとおり、テーブル構造とUIの要件が合ってないと、非常に困難になる機能でもあります。
（もっとも、ストアドプロシージャでグルグルまわせばどんな処理でも出来ますけれど……）

だからこそ、UIを先に作る。
UI側はテーブル構造を一切気にせずに、ダミーのストアドプロシージャでUIに必要なデータを作る。
そのダミーのストアドプロシージャを見て、UIにデータを返しやすいテーブル構造を作る。

という流れの方が良いわけです。

最悪、ストアドプロシージャでグルグル廻せば処理できるし、Javaで廻すよりパフォーマンスは良いですよ。

うーん、私が根本的な疑問として持っているのは、

SQLをデフォルト言語にしちゃっていいのか？

という点です。

永続化と問い合わせの手法一つとっても、OODBMSやXMLDBMS、GFS+MapReduce(的なもの/Hadoopとか)とかその時々で最適なものは変わってきますよね？
私が知らないだけで、他にも色々あると思います。ネットワーク型とか階層型とか、名前しか知りませんし。
でも、SQLで考えろと言ってしまうとそこで思考停止しかねません。

だから、生島メソッド(勝手に名前をつけてすみません)の適用可能範囲(と適用不能範囲)をはっきりさせて欲しかったわけですが、どうも私の訊き方がまずいようで期待していた答えは得られませんでした。
生島さんは適用範囲のことはあまり頭になかったみたいですが、どんなプロジェクトにでも適用できるということはないはずです。

かつて、XP入門が日本で出版されたとき、適用範囲をはっきり指定していることに衝撃を受けました。
それまでの開発方法論は、パラメータをいじればどんなプロジェクトにも対応できます、というものだったからです(RUPが典型)。
ここまでの印象では、生島メソッドもかなり限定された領域でうまくいくように思います。
XPの例を挙げるまでもなく、領域を限定するのは方法論の価値を上げていく上で必須ですから、もう少し技術的な面から詳細な領域定義が欲しいですね。

それにしても、仕事をしている場所(レイヤー)が違うせいか、同じ単語をどの程度近い意味で使っているのかがかなり不安、というか通じてないんだろうなという箇所が多いですね。

> もっとも、現在の上流・下流という分け方になっているためです。

上流・下流の分け方は、うまくいかないことも多いでしょうね。
と、他人事なのは、そういう分け方をする環境で仕事をしたことがないからですが。
なので、問題意識のレベルでかみ合ってないかも知れません。
＃受託開発に文句があるなら、Web上の自社サービスやパッケージやればいいじゃん、と思ってしまう。

ちょっと前にERPパッケージを作っている人に話を聞きましたが、そこも上流・下流という分け方はしていないようです。
機能(モジュールって言ってたかな)ごとに担当者がついて、仕様の決定から実装まで全部やっているそうです。
ただ、この作り方だと機能間の連携がどうしても弱くなるため、そこが欠点ということでした。

> http://www.g1sys.co.jp/column/_2006_11_10.html

読みましたが、下手に作れば(負荷の集中を避け損ねれば)ちゃんと動かない、以上のことは言っていないように見えます。
逆に、うまく作ればAPサーバ側に負荷分散させてスケーラビリティを上げることもできそうです。

> http://otn.oracle.co.jp/forum/message.jspa?messageID=28019300

これはSQLの「べからず」集としていいですね。
参考になるページを紹介してくださって、ありがとうございます。

SQLと手続き型言語のどちらで実装するかの切り分けですが、

集合理論で扱える部分はSQL、それ以外は手続き型言語(および関連するその他諸々)

というのはどうですか？
定期的な予定は、集合理論で扱わない領域だと思って例に出しています。

> SQLをデフォルト言語にしちゃっていいのか？

全然問題ないと思います。

> 生島さんは適用範囲のことはあまり頭になかったみたいですが、どんな
> プロジェクトにでも適用できるということはないはずです。
……
> もう少し技術的な面から詳細な領域定義が欲しいですね。

適用範囲はRDBMSを使うシステムです。（何度か書いたと思います）
SQLが得意でない人は、SQLの限界値を低く見積もるので「どんなプロジェクトにでも適用できるということはないはずです」となるのでしょうか？

問題は、同様に考える人が多いから邪魔をしてくることです。

> 永続化と問い合わせの手法一つとっても、OODBMSやXMLDBMS、GFS+MapReduce

そもそも適用範囲外です。
UIの検討に入るまでDBが確定していないというような特殊なプロジェクトがあるのかもしれませんが、一般的ではないのでそこを議論しても仕方がないです。

> > http://www.g1sys.co.jp/column/_2006_11_10.html
>
> 読みましたが、下手に作れば(負荷の集中を避け損ねれば)ちゃんと動かない、
> 以上のことは言っていないように見えます。
> 逆に、うまく作ればAPサーバ側に負荷分散させてスケーラビリティを上げる
> こともできそうです。

DBサーバで下手糞に組んだときというのは考えていないけれど、そういうことですか？
下手糞に組んだらどんな組み方でもダメですから、比べる必要がないのでは？

全体でやらないといけない処理は変わらないのです。
APサーバに処理を振ってDBサーバの処理を肩代わりしていなければ、スケーラビリティが上がることはないのです。
APサーバで（業務ロジックを）処理してDBサーバの処理のどこが減るのでしょう？
ほとんど減らないのです。

> 定期的な予定は、集合理論で扱わない領域だと思って例に出しています。

判らないのですけれど、どのような結果が欲しいのでしょう？

祝日マスタと予定パターンデータがあるとします。

例えば、DBサーバにリクエストを出さず、無限に毎月5日に予定を入れたい。
であれば、UI側は祝日マスタと予定パターンを読み込みUI側で処理すればいい。
これはUI（外部）の処理でしょう？

ところが、毎月5日に予定を入れても、それを前後にズラすことも考えられます。
では、永続化しなくてはいけない。

永続化するのに、無限にデータを作るのは無理があるので、例えば100年でもいいし、祝日マスタが存在する間でもいい。
祝日なら後ろへズらす。というルールのもと永続化するとします。
これはSQLで可能です。

ただし、予定が他の予定と重複する日も出てくるでしょう。これをユーザに問いただすか、どうか要件によって変わります。
ユーザに確認する必要が出てくれば、UI（外部）の処理ですね。

外部と内部を分けるべきで、「内部はSQL」とお話しているつもりですけれど。
MVCのMの部分はSQLでということです。

> 定期的な予定は、集合理論で扱わない領域

MVCがごっちゃになっていると思います。

私が思うに、上流工程＝技術知識が無くてもいいという馬鹿な考えが蔓延したのが一番のミスだと思います。
そもそも、知らないものをどうやって作るのでしょうか？
それを解決するための方策として「SQLを覚えろ」というのは結構効果があると思います。
というのも、駄目な設計者は兎に角頭の中で情報が整理されていません。
その混乱した情報素人をどうにかしようと思ったら、頭を整理するためのツールが必要となります。
SQLをちゃんとマスターしようとすると、正規化を覚えなくてはなりません。
正規化は情報を整理する上で非常に優れたものです。
お客様の話しを聞くのと同時にシステム情報の正規化を行うと、お客様に何度も要求を聞いたり重要な事を聞き逃したりせずに済みます。
お客様は何度も聞かれる事を疎んじますから此れは重要です。
ですから、情報の正規化が行えるとその場で聞けるようになりますので、上流の人は身につけておくべき技術です。
普通に考えれば「家の建て方を知らない人が家を立てられない」と思います。
それが出来るのならば、発注なんてせずにエンドユーザーが作ってしまうでしょう。
何故そんな小学生でも分かる理屈がこの業界では通用しないのか不思議でなりません。

これは余談ですが、OODBMS、NXDBMSでもシステム情報の正規化技術は必須です。
DBMSはデータを管理する技術ですから、ある程度は整理されていないと駄目です。
巷でよく誤解されるのですが、NXDBMSでもデータの整理をしておかないと管理できないのです。
OODBMSについては、「クラス設計を考えずにオブジェクト指向なプログラム言語を使いこなせるか？」と考えれば自ずと答えは導き出されます。
階層型データベースについては、Windowsのレジストリが良い例です。
こっちの方がよりデータを整理整頓しないとシステム構築は出来ません。

私がシステム構築の仕事をする時は常に、頭の中でシステムで発生する情報を棚に並べています。
その時一番有効なのは、オブジェクト指向で考えるのと同時に、リレーショナル理論とプロセス指向でも検討する事です。
オブジェクト指向はリレーショナル理論とプロセス指向が必須です。
ですから、いきなり上流の人に「オブジェクト指向で考えろ」と言っても無理ですし、プロセス指向＝機能分割法は難しい事で有名なので駄目です。
ですから、その中で一番やりやすいのがリレーショナル理論で考える事なのです。

インドリさん

おっしゃるとおりです。
私も料理をしたことない人がレシピを書くとか、仕様書だけ書くのは味見なしでレシピを書くとか、まぁ、そんなとこですね。

オブジェクト指向派は、SQLなんて変な言語使わなくてもできると考えるでしょう。パフォーマンスが問題になればSQLでやり直すけれど、それまではオブジェクト指向でいいんでないの？

というのが一般的です。

これは、オブジェクト指向がSQLでやるよりも工数が掛からないなら、ある程度正しい方法論だと思います。

しかし、最初からSQLでやった方が工数が掛からないなら、SQLでやるのが妥当でしょう、という実に単純な問題です。

インドリさん
> 私が思うに、上流工程＝技術知識が無くてもいいという馬鹿な考えが蔓延したのが一番のミスだと思います。

どこで蔓延しているのかは知りませんが、その種の愚痴はBlog等で時々見ますね。
その解決として上流技術者に技術知識を持たせるくらいなら、上流・下流の区別をなくして実装まで全部やればいいのにと思っていますが、何が壁になっているんでしょうか？

> その時一番有効なのは、オブジェクト指向で考えるのと同時に、リレーショナル理論とプロセス指向でも検討する事です。

結局、全部知ってた方がいいというのに異論はないです。

> オブジェクト指向はリレーショナル理論とプロセス指向が必須です。

オブジェクト指向がリレーショナル理論とプロセス指向で代替できるなら、O/Rマッパーでことが済む世界になっていたはずでは？

生島さん
> 最初からSQLでやった方が工数が掛からないなら、SQLでやるのが妥当でしょう、という実に単純な問題です。

やっぱり通じませんね。
方法論が有効に機能する条件、つまりSQLでやった方が工数が掛からない条件を提示すべきではないかと言っているわけですが。
それをRDBMSを使う案件すべてと仰るので、堂々巡りになるんです。
私の案は先に書いたとおり「集合理論で扱えるか」です。

> APサーバに処理を振ってDBサーバの処理を肩代わりしていなければ、スケーラビリティが上がることはないのです。

だから、肩代わりできないような拙いコードにしちゃったのが問題だというだけのことです。
ちゃんと肩代わりしてやれば、スケーラビリティが上がるというのを否定されいるわけではないですよね？
APサーバ側でうまく組んだケースを無視して「洒落にならない誤解」とされているので、コメントしただけなんですが。

> MVCがごっちゃになっていると思います。

うーん、Model-View-Controllerの定義が私と違う？
MはVやCと対話します。
この場合は、Vである予定表UIがM(予定表オブジェクト)に対して「私はどの期間を表示すべきか、その期間内であるN月M日にはどんな予定があるか」を問い合わせます(期間はCがMに与えます)。
MはDB等に永続化されている予定のデータを取得し、それが定期的な予定であれば実日付に展開してVに教えます。Vが定期的な予定をそのまま扱うことはありません。
こうすることでテストの難しいVの複雑性を抑え、品質を高めることができます。
実日付に展開する処理をSQLでやれるか、というのがずっと問題にしていることですが、どうも無理っぽいですね。

でも、生島さん案だと、モデル=DB上のデータで、展開はVがやるということになるようです。
それはVに責務を押しつけすぎではないですか？

> 方法論が有効に機能する条件、つまりSQLでやった方が工数が掛からない条件
> を提示すべきではないかと言っているわけですが。
> それをRDBMSを使う案件すべてと仰るので、堂々巡りになるんです。
> 私の案は先に書いたとおり「集合理論で扱えるか」です。

堂々巡りですけれど、少なくとも基幹システムは適用可能ですから、いわゆるSIerのかかわるRDBMSのほとんどのシステムで適用可能です。

> Vが定期的な予定をそのまま扱うことはありません。

そのまま扱うことがなければ、DBに戻さないといけないでしょう？
であるなら、DBが展開するのはおかしいでしょう？

> 実日付に展開する処理をSQLでやれるか、というのがずっと問題にしている
> ことですが、どうも無理っぽいですね。

初期データを展開したいというのであれば、

> 祝日なら後ろへズらす。というルールのもと永続化するとします。
> これはSQLで可能です。

永続化するというのは、以下の様な形になります。
INSERT INTO 実スケジュール
SELECT … FROM 定期予定 … 稼働日マスタ …（デカルト積）

あるいは、
INSERT INTO 実スケジュール
SELECT … FROM 稼働日マスタ …
WHERE 稼働日 IN(SELECT 日付 FROM 定期予定 … )

みたいな形かも知れません。

稼働日マスタは100年分で37000件未満ですね。
年月日をバラしてそれぞれにインデックスをつけておきます。
という形で出来ます。もっと複雑な工場ラインの山積み・山崩しでも出来なくないです。

これらは、一例でいろんなパターンがあって、最適のパターンを選択するために、テーブルの設計を実装の後にすると……。

永続化しないパターンはINSERTの後ろのSELECT文ですから、初期表示したいのであれば、後ろのSELECT文だけ使えばよいのです。

また、あるときは永続化されたデータ、あるときは自動生成して表示というのは、システムとしてよろしくない。
ですから、永続化するなら、新規に繰り返し予定が登録されたときにバッチ的に先日付まで予定を埋めて再表示する方がロジックはすっきりするでしょう。
ポストバックがイヤと言われれればUI側でも処理するかしかないですね。

しかし、永続化されたスケジュールを表示して、ユーザが手直ししていく処理を考えると、いちいちDBに入れてからではなく、最後の保存ボタンで一気に更新する方が要件に合うかもしれない。
DBに入れてからREDOを作るのは、UIからもDBからも見ても面倒でしょうから、最後に画面丸ごと送信する方が要件に合うかもしれない。

REDOは必要ないかもしれないし、1スケジュールごとにDBに入れた方が良いかもしれない。

この辺はユーザの要件によって違うし、他にもユーザからの要件はたくさん出るでしょう。

本文で書いてあることは、そのユーザの要件が確定するまでDBを確定しない。
確定しないために、UI側が渡せるパラメータと、必要なリターンのダミーを作って（……本文見てください）。

特にこのようなUI側の要求が厳しくなるパターンは、紙で仕様を固めようとしたり、テーブルを先に作ったりすると痛い目にあうシステムです。

ですから、繰り返しますが、UI側は、DB側の処理を一切気にせず、渡せるパラメータ（共通も含む）と、必要なデータをダミーのストアドで作ればよいのです。

つまり、RDBMSを使う限り、どんなシステムでも適用可能です。

追加。

デカルト積というのは、FROM句でJOINしないパターンです。
テーブル通しの全部の組合せになりますから、場合によってはとてつもないデータをメモリー上に展開してしまう可能性があります。

しかし0～9までの数値を持ったテーブルを一つ用意しておけば、元データを何倍にも水増しできます。

レコードを10000万倍にする方法です。

SELECT m.ID + n.Num + 1 ,m.Name || TO_CHAR(n.Num) --ORACLEや…
FROM 元テーブル m,
　　(SELECT a.Num*1000 + b.Num*100 + c.Num*10 + d.Num AS Num
　　FROM tblNum a, tblNum b, tblNum c, tblNum d) n

ループ書けば良いのですけどね…。
私はアルゴリズムがしみこみすぎた人には練習としてやらせます。

> SELECT … FROM 定期予定 … 稼働日マスタ …（デカルト積）

すみません。よく考えたらOLAP関数を使わないといけないかも知れません。
でも、まぁ、数行変わるぐらいのことです。

うーん、つまり基幹系システムでなら使えるということでしょうか。
RDBMSならなんでも、に比べるとかなり限定されましたね。
これ以上は、日本語が通じてる気がしないので追求しないことにします。

> SELECT 日付 FROM 定期予定 …

稼働日(祝日)のことは忘れてもらっていいです。そこは本質じゃないので。あと、想定しているのはGoogle CalendarとかYahoo!カレンダーとか、ああいうのです。
で、定期予定テーブルにパターンが入っているとして、例えば「2009年1月26日以降2年ごとの6月第4月曜日」と「2008年10月3日以降3週ごとの月・水・金」を2009年分に関して展開したい場合、FROM以降になにを書けば日付の集合を得られるのでしょう。

ぱっと思いつくところだと、

SELECT
予定のID,
CASE パターン
WHEN '年次曜日指定'
-- add_months/next_dayと数列テーブルの組み合わせ
WHEN '年次日付指定'
WHEN '月次曜日指定'
WHEN '年次日付指定'
-- 省略
WHEN '繰り返しナシ'
日付
AS 日付
FROM 予定表, 数列テーブル
WHERE 日付 >= 2009年1月1日 AND 日付 < 2010年1月1日

辺りですが、以前生島さんが書かれていたようにCASE～WHENを使わずに書けるのでしょうか？
また、APサーバでも書けるロジックをRDBMSに処理させるのは、スケーラビリティの面で不安があります。

一般的には基幹システムに存在する機能よりマイナーなような気がしますが、良いでしょう。

そちらの方が簡単になりましたよ。
関数で第何週や曜日は出ますけれど、カレンダーマスタで静的にもっておけばよいでしょう。

　　日付,年,月,日,曜日,日付シリアル,第何週,週シリアル,月シリアル

と持っておけばいいのです。
1レコード100Byteもいきませんけど、100Byteとしても100年分で4MByteですから。

3週ごとなら週のシリアルを3で割ってあまりを見ればいいでしょう？
第何週ならそのものずばりをWHERE句に書けばいい。
Googleとかも、RDBMSを使っているかは知りませんけれど、静的な日付マスタは持ってるはずで、処理しやすいデータの持ち方をしているはずです。

というように、要件が決まればテーブルも決まるのです。

そして、要件というのは、先ほども書きましたが、ユーザがメモリー上（画面）で処理してメモリー上（画面）で確認後に更新すべきなのか、パターンを決めたと同時に永続化すべきなのかによって、外部の要件なのか、内部の要件なのかも変わります。

要件によって、UI側が求めるデータも違うでしょう。
しかし、ユーザとアジャイルで打合せをする際に、テーブル構造を無視して、UIにとって一番簡単に処理できるデータ形状の要求すればよいのです。
ただし、ユーザオペレーションに1回から固定で数回まで（ループの中で要求しない）にする。

何度も書いてますけれど、どうしようもないときは、ストアドプロシージャ内でワークテーブルを作ってループしながら埋めればよいのです。
それでも、Javaなどでループするより効率的に処理できます。

というわけで、くどいですけれどRDBMSを使うシステムすべてに適用できます。

> 日付,年,月,日,曜日,日付シリアル,第何週,週シリアル,月シリアル

なるほど、ロジックじゃなくてデータで全部持っちゃえと。これは思いつきませんでしたが、よく考えたら重い演算の結果を配列に入れておくのと一緒ですね。
現実に適用するとなると色々問題は出そうですが、ひとまず納得です。
＃でも、カレンダーマスタのどのカラムを見るかはCASE～WHENを使わないと書けないような…。

> というわけで、くどいですけれどRDBMSを使うシステムすべてに適用できます。

それなりにいけそうですね。
相変わらずスケーラビリティに不安は残りますが、そこは適用範囲から外しちゃえばいいだろうし。

祝日をズラすのは、SQLServer2005のOLAP関数ではうまくいかないことが分かりました。Oralceなら簡単ですけれど。
これはちょっと面倒なのですけれど、要件としてどうしてもあるなら、データとして持っておくこともあります。（休日が変わるたびにメンテが必要ですが）

日付, 休日フラグ, 前倒日, 後倒日
2009/1/1, 1, 2009/1/5, 2008/12/26
2009/1/2, 1, 2009/1/5, 2008/12/26
2009/1/3, 1, 2009/1/5, 2008/12/26
2009/1/4, 1, 2009/1/5, 2008/12/26
2009/1/5, 0, 2009/1/5, 2009/1/5
2009/1/6, 0, 2009/1/6, 2009/1/6

もちろん、WHERE句で絞った後、利用するのは、何も考えずに前倒日だったりします。

余談ですが、せっかく静的に持っているのに、

日付, 休日フラグ, 前倒日, 後倒日
2009/1/1, 1, 2009/1/5, 2008/12/26
2009/1/2, 1, 2009/1/5, 2008/12/26
2009/1/3, 1, 2009/1/5, 2008/12/26
2009/1/4, 1, 2009/1/5, 2008/12/26
2009/1/5, 0, NULL, NULL
2009/1/6, 0, NULL, NULL

さらに判断を入れるような人もたまに……、いや結構……。

tripod さん

>その解決として上流技術者に技術知識を持たせるくらいなら、上流・下流の区別をなくして実装まで全部やればいいのにと思っていますが、何が壁になっているんでしょうか？

上流技術者が学ばない方が儲かる現実が一つ目の壁になっていると思います。
何もしないほうが儲かるのならば、多くの人間は学ばない方を選ぶでしょう。
効率から考えると、エンドユーザーと直接、データベースエンジニア、ソフトウェアエンジニア、ネットワークエンジニア、セキュリティエンジニア、プログラマの各代表が話せば速いのですが、何もしない会社が儲かるにはその対面上、子供の使いを送るしかないようです。
直接システム実装者達がお客様に会ってしまうと、何もしない会社の悪事がばれてしまいますからね・・・
二つ目に、システム構築は大まかに分類すると、分析・設計・実装の三段階に分かれているのですが、実装段階になるまでは【実装を意識してはならない】ので、そこを誤解しているようです。
意識してはならないのと、無知でいいのとは別物だと思うのですが・・・
最後に日本人の組織文化が悪影響を与えているものと感じます。
日本では肩書きにより報酬が決まりますので、上流技術者というレッテルを貼ったからには下流の仕事をさせられないという考えのようです。
情報処理技術は常に進化しているので、常に触っていないと駄目というのが経営層の人は分かっていないようです。
経営者も自分が売るものを知っていないとならないのに、知らないものを売ってもいいという、非倫理的かつ非生産的な考えが世間で蔓延しているようですね。
私としては、知らないものを売った時点で品質を気にしていない事を意味するので、偽装食品を売った人となんら変らないと思うのですが・・・

>オブジェクト指向がリレーショナル理論とプロセス指向で代替できるなら、O/Rマッパーでことが済む世界になっていたはずでは？

いいえ。あくまでもオブジェクト指向はデータ＋プロセス＋αなので、他の指向も併用しなければならないという事です。
よくある間違いが、オブジェクト指向はソフトウェア工学的に歴史を積み重ねて出来たものと言う単純な事を忘れてしまう事なのです。
使えるものは全て使わなくてはなりません。
それに、O/Rマッパーはあくまでも道具であって、設計者の思考技法ではないので解決策にならなかったのだと思います。
○○指向も適材適所なのです。

> 上流技術者が学ばない方が儲かる現実が一つ目の壁になっていると思います。

本人は「勉強しない方がも儲かる」とまで思っているかは微妙ですけれど、ある程度当たってます。
どうせデスマーチで疲弊するぐらいだったら、先に1ヶ月ぐらい勉強の時間を与えてあげればいい。その代わり、1ヶ月後にあるスキルまで到達できなかったら、既得権を剥奪すればよいのです。
必死になれば、SQLぐらいのもの簡単なことですわ。

私は、そんな思いで会社を始めたのですけれど、この思いは伝わらないね……。

生島さん、こんにちは。

>私は、そんな思いで会社を始めたのですけれど、この思いは伝わらないね……。

そうなんですよね・・・私もおそらく同じ思いを抱いております。
一番不思議なのが、エンドユーザーが何もしない会社に大金を出している事実です。
なので、スーツ族と一緒に仕事した際に次のような会話をした事があります・・・

スーツ族「お客様はシステムじゃなく、ブランドを買いたがっている。だから、ブランドを掲げて、お客様に夢を売るのが一番儲かるのだよ。いっている意味分かるよね？」
私「・・・それは、同意しかねます。」
スーツ族「だから君は負け組みなのだよ。大人になり給え。君はIT用語を山ほど知っているのだから、我々と一緒にお客様に夢を売れば直ぐに年収は億単位になるぞ。お客様がそれを望んでいるのにそれを拒否する理由はあるのか？」
私「あります。私は職人になりたくて情報処理技術を日夜学んでいます。確かに貴方の仰る通りの事をした方がお金持ちになれるのかもしれませんが、私はシステムを作って正当な報酬を得たいのであって、その様な手法で儲けたいとは思いません。例え貧乏であっても、負け組みであってもかまいません。」
スーツ族「ふん、それは自己満足に過ぎんな。どうやら、君は負け犬根性が身についてしまってるようだ。断言してもいい。お前は一生負け犬だ。」

悔しいけども、これが現実なんですよね・・・
私自身はそれでもいいと胸を張って生きていますが、曲げられない不条理な現実がそこにあります。

不況ですからね、本物じゃない人は淘汰されますよ。
まぁ、その前に私が淘汰されそうですけれど（苦笑）
上手に生きたら、儲かる方法はわかってますが、今まで批判してきて、それに乗っかるわけには行かない。

同じように独立した人の中には、「新しい業界を作ってやる！」っていう人もいる。でも、私は「業界を変えてやる！」です。