SQLの方言、複雑なSQLは遅い、スケールアウトについて
SQLにロジックを入れるにあたり、必ず問題になるのが表題の件。
■ SQLの方言について
違いはあります。違いを大きいと感じるか、小さいと感じるかは人それぞれでしょう。同じだと思っていると戸惑うかもしれませんが、違いがあることを認知していれば、個人的には簡単に乗り越えられるレベルと感じています。
わたしが経験した順に。
● Access
RDBMSとはいえないけれど、パーソナルツールとして卓越していると思います。アドホックな仕事には最適ですね。
SELECT句、FROM句にサブクエリーが書けないと思っていました（たぶん、2.0ではできなかったと思うけれど……もしできてたら、苦労したから悔しい。手元にある一番古いAccess2000でも簡単にできてびっくりしました）。
● Oracle
ずいぶんやったな～。
メジャーではあるけれど本当に癖が強い（と思う）。テーブルのエリアスを指定するときに"AS"を書いてもいいんじゃないの？ UPDATEとかでテーブルのエリアスを指定できないってどうにかできないのか？ WHERE句にサブクエリーを書くとき滅茶苦茶不便なんだが……（勘違いだったらごめんなさい。11gはまだ触ってないからできるようになってたらすみません）。
8iぐらいまでは、外部結合を(+)でWHERE句に書いていましたが、それには非常に違和感をもっていました。処理から考えると正しいと言えますけど、ここは微妙なところですね。
9iから（？）FROM句にJOINを書けるようになりました。
● SQLServer
ストアドプロシージャを使ったコーディングが滅茶苦茶に楽です。結果セットを簡単に返せるのは本当に便利です。.NETとの親和性はとてもよい。当たり前か。Oracleから移行しましたが、違和感は全然なかった。
思いっきり余談ですが、OracleがISOで、SQLServerがANSIに寄せたのかな？ ISOは非英語圏に配慮して(+)のような記述を推奨したのかと、なんとなく思っているのですが……。
● PostgreSQL
趣味で初めて使ってみたときは外部結合できなくって、別途UNIONする必要があったりしました。とても実務では使えなかった。しかし、現状のバージョン（8.3）では、OLAP関数が使えないのがつらいけれど、かなり満足できます。
● DB2
2つのプロジェクトしか経験がなく、どちらも、いきなりデスマの中へ入ったけれど何の問題も違和感もなく使いこなせた。
● Pervasive.SQL
Betriveか……。
検証はしたことがありますが、実務では使ったことがありませんので詳しくは分かりません。検証中に、OracleやSQLServerとの違いをざっくり見たのですが、1日も見れば使えると判断はしました。
● MySQL
ECCUBEなどを手がけているのでよく使います。
単機能を実現するのには非常にお手軽ですが、基幹業務にはとても使えない。
他にも使っているかもしれませんが覚えているのはこれぐらいかな。ベンダーごとに方言も機能の差もあります。だから、初めて触るときは、同じところと違うところを意識しながら、軽くリファレンスを流し読みすれば事足りると思います。
それこそ、標準語と大阪弁ぐらいの差しかありません。
東京へ行くと、「今度の電車」って何？ （大阪では先発、次発）とかね。確かに？？？ って思うけれど、たちまち電車に乗れなくなることはないのです。もっとも、地下鉄ではよく迷子になるけどね。
■ 複雑なSQLは遅い
これはどうしようもない間違い。
× 複雑なSQLは遅い
○ 下手糞に書いたSQLは遅い
です。複雑だから遅いのではなく、下手だから遅いのであって、「複雑なSQLは遅い」という人は、「わたしはSQLを分かっていません」と宣言しているのと同じです。（F1ですらセミATになって久しいですが）複雑なSQLはミッション車と考えてください。
「複雑なSQLは遅い」という人は、ミッション車で「シフトチェンジすると車が壊れたり、事故をしたりするから、1速に入れてそのまま運転するのが正しい」と言ってるのと同じです。シフトチェンジができないという特殊な前提の中では正しいですけれどね。自動車（RDBMS）の能力は数分の1も使えていません。
「複雑なSQLは遅い」という人は「自分はSQL（RDBMS）はできない」と宣言しているのですから、テーブル設計をする人間からはずすべきで、そのレベルで（テーブル設計などができる）技術者を名乗ったら詐欺師以外の何者でもない。UI側の言語や、インフラなど能力は別途評価すればよいですが、少なくともテーブル設計などに携わったりしたら、何年にも渡るどうしようもない障害を残すことになる。
もっとも、できない人が圧倒的に多いということを考慮に入れるかという問題は、わたしも抱え続けている。しかし、できない人を教育するという方向へ向かった方が、教育費と工数とパフォーマンスなどを考慮すると効率がよいと考えています。
これはVB6と.NETとは逆の答えになりますが……。
そもそも、SQLなんて簡単なので、ちゃんと教育すればできるはずです。
■ スケールアウトについて
● クラスター化
個人的にクラスター構成はOracleでしか経験がない。Oracle RACかなりイケてます。
Oracle10gからはStandard Editionでも使えるのがありがたい。クラスター化されればコーディングレベルでは特に気にすることなくスケールアウトできます。ただ、WEBシステムでAPサーバとの間にロードバランサーを挟んでいると（はさむよね）、データが下手に分散してしまうので、APサーバの共通部分でいろいろと工夫しないとまずいことになりますね（わたしはそこは担当したことがないけど）。
流通大手の実績（Oracle RACで都道府県ごとに1台から数台という分散方法）を拝見しましたが、わたしの想像以上に大きなものも可能なようです。もっとも、ハードとライセンスだけで何億よ？（定価で買ってたら……）と思うほどですが、規模によっては費用対効果を考えると成り立つのでしょう。
Postgre Forest は提案するために相当に調べ検証しました（結局使われず）、ほとんどお手製クラスター化という感じで、やってやれなくはないけれど、構築は大変だとの印象です。PostgreSQLでホットスタンバイという構成は経験があるけれど、 これも結構大変でした。
個人的な趣味ではPostgre Forest を猛烈に試してみたいけれど、それとビジネスは別で、クラスター構成にせねばならない規模の案件では、商用DBを勧めるかな。自社のサービスを立ち上げるときはPostgre Forest を使うことになるな。いつになることやら。
● スケールアウトするということ
スケールアウトしなければならない状態ってどういう状態なのか考えてみましょう。
対象の企業が、「ムーアの法則を超える急成長をした」というめでたい話は稀なのではないですか？
ムーアの法則通りにはDBは速くならないが、常識的な成長率であれば、ハードをリプレイスすれば事足りるでしょう。
ムーアの法則を超える可能性があるのはベンチャーや新サービスで、無料サービスで無理やりシェアを取りにいったりしたパターンでしょうか。元が極めてゼロに近いので一般的なサービスになったとしたら、ものすごい成長率になってしまうことはあり得る。
ところが、そのような案件は初期に売上＆ユーザがゼロに近いことになるので、SIerに依頼することすら少ないでしょうし、成功する可能性が低いために初期にはコストは掛けれない。結果、初期はできるだけ安く作って、すさまじい勢いで増える状況になったとき、並行して作り直していくしかない。
Twitterにしても一気に伸びたけれど、どちらかというとストレージとしての機能を求められる。現状では複雑な集計などいらないし。この辺は業務システムじゃないので、本文の対象外ですけれど、ユーザ情報などは別途RDBMSに入れた方が効率的だと思う（どんな構成になっているかは知らない）。たとえば、将来、課金したいと思ったときにストレージというとらえ方をしていると大変なことになるでしょう。
1000万人分ぐらいなら、抜き取ってすぐにRDBMSで構築できるけどね。
とにかく、何もひとつにこだわる必要はない。しかし、「SQLはよくわからないから嫌だ」という感情が乗った意見はまったく無価値です。
他では、たとえば合併が起きたような場合もあり得ますが、それは予想がつきませんし、それまでを想定して作ればオーバースペックの提案になります。現実にSQLを極力廃したシステムを採用していて、偶然にも合併となったパターンも見ましたけれど、目論見どおり工数が減ったかというと、作り直しと同じでした（笑）。
● スケールアウトが必要になる原因
普通の会社で、ムーアの法則を超える成長はないのです。それなのに数年で簡単にパンクさせてスケールアウトしなければならないことが起きるのはおかしい。
スケールアウトしなければならない事態というのは、ほとんどは初期の見積りミスといえるのですが……。それを上流の技術者が言うということは、自分の見積りには「まったく自信がない」と言ってるのと同じでしょう。
もちろん、ロードマップとして、数年後には「ハードの追加が必要」と計画している場合もあるけれど、そのときは、最初からクラスター構成にしているはずで、2台目以降は基本的に同じ（設定変更までですむ）ように設計すべき、システムの構造が変わらないからSQLで処理しても何の問題もないのです。
普通、プロが見積もってたら予想できるでしょ。ということは、現実的にどうしてもスケールアウトしなければならないというのは……、下手糞な構造、下手糞な設計、下手糞なコーディングが原因だろうと思います。
ぶっちゃけ、「これどう見てもオーバースペックやろ？」ってサーバでもパンクさせる奴はパンクさせるからな～。
■ まとめ
確かに、RDBMSで、最初からシングルの構成で見積もっていて、途中でクラスター化しなければならない事態になったとき、それはそれは大騒ぎになりますが、わたしには、なぜ見積り段階で分からないのか理解できない。
みんな結構細かいことを「仕様変更だ！」って騒ぐけれど、スケールアウトせねばならない状況が見積りの段階で分かってないなら、完全な仕様変更で、その変更費用を拒否する顧客はまずいない（出せない顧客は残念ながらいる）。その規模になれば、合併の例を出すまでもなく、SQLを排除していても、大抵、単純な工数では終わらないし、むしろ、規模が大きくなればパフォーマンスの問題で、もっと大きなトラブルが起きることの方が多い。
もちろん、ケースバイケースですけれど。
逆に考えると、DBサーバを変更するというのはそれだけ大変なことなのです。ということは、たとえば、5年後にOracleからSQLServerに変わることは同じ理由で極めて少ない。RDBMSというくくりの中では、癖の違いはあってもベンダーごとの差はほとんど出ないところまで来ているので、ユーザに変更するコスト負担を求めるのは非常に難しいわけです。
変わる可能性があるとしたら、まったく別のアーキテクチャに変わることになるでしょう（これが予想できたらビルゲイツを超える可能性もあるよね。わたしは予想できないので絡まないでね）。
と考えると、「方言の違い」というごくごく小さなことがなぜ気になるのか、なぜ問題になるのかわたしには理解できません。
わたしの十数年の経験でいろんなRDBMSを使ってきたけれど、同じ顧客でRDBMSが変更されたというのは少ないです。フロントエンドの言語が固定でRDBMSが変わったことは基本的にパッケージ以外にない。逆に、フロントエンドの言語やアーキテクチャが変わることはよくありました。
C/SからWEBシステムへなんてドラスティックな変更を何回もやってますけど、RDBMSは変わらない（バージョンアップ・ハードリプレイスまで）。まれに、Oracleのライセンス費がもったいないから、PostgreSQLでって変更もあるけど、変更工数よりOracleのライセンス費の方が安いしね～。
オヤジの目からすれば、Javaだって1回消えてるし……。（何をもって消えたかという定義は難しいが）Silverlightだ！ Flexだ！ って、流行る前に消える可能性だって高いと思う。それに比べて、OracleやSQLServerやDB2やその他のRDBMSが、フロントエンドの言語と同じ時間軸では消えることはないと断言しておきます。
逆にDBは変わらないのだから、スケーラビリティをあげるためにも、ロジックを極力DB側に詰め込むべきだと思いますけどね。
将来の予測は確率論でしかないわけです。確率的にどちらがベターかという話であれば、もうフロントエンドの言語にロジックを入れるなんて「あってはならない」と断言してよいぐらいの確立で変わりますけどね（VS2010が出たら、また騒ぐくせに……とか思ってる）。
わたしの考慮漏れなのか「SQLはダメだ」という言い訳には、どれも苦しいと思う。みんな視線が低すぎやしませんか？
というわけで、SQLにロジックを入れない方がよいという一般的な理由に反論してみました。自分ができないからイヤという、およそプロとは思えない言い訳以外の反論は大歓迎です。
わたしは生のSQLを一切書かない、すべてストアドプロシージャというプロジェクトを何本もやっています。逆に、SQLに処理を書かないプロジェクトも何本も経験があります。
両方のやり方で、相当数こなした上でSQLに入れた方がよいといってるのです。が、ものすごく腹が立つのは、SQLに処理を書くことに反対する人は単にSQLのスキルが低い、その上SQLで処理するというプロジェクトを経験してないということ……。
「メンツが揃わないから現実的には無理」というのは、ものすごく消極的に賛成せざるを得ないことがあるのですけれど、それを言ってるからいつまでたっても変わらないだけです。
あと、技術者に必要なのはSQLだけじゃないという当たり前の話はご勘弁を。SQLのスキルは必要条件であって、十分条件ではありませんし、誰も「SQLだけでよい」などとは言っていません。
ただし、一般的にもっとも不足しているスキルです。
コメント
ちょっと質問
DB側にロジックを詰め込みたいとのことですが、構成管理上あまり嬉しくない気がします。
DBはある意味バージョン管理や継続的統合との相性が悪いと感じており、ロジックをDBに持たせたくないというのがあります。
そこら辺をどのように解決しているのか非常に気になります。
例えば、言語側にロジックを持たせている場合、修正はITSでチケットを発行し、コードを修正後コミット後、自動でリグレッションテストが走ります。
その後、チケットをクローズし、リリースという流れになるかと思います。
また、バージョンを戻したい場合もタグからチェックアウトしてビルドするだけで戻ります。
このあたりをDBにロジックを入れても問題なくできるようなら、DBにロジックを入れてもいいかな、と思えるのですが、こういったことが上手くできないため、そうは思えません。
このあたり、どのように実現しているのか、教えていただけないでしょうか？
お答えする前にお伺いしたいことがあります。
あなたは、数ある設計書のバージョン管理をどのように行っていますか？
それが、ストアドプロシージャなどDBに入れた場合とどのように違いますか？
あなたはVB6から同じベンダーの.NETに移行するに対しての大騒ぎをどのように感じますか？
逆に、RDBMSでバージョンアップに対してどれほどの差がでましたか？
その差が出たとして、http://el.jibun.atmarkit.co.jp/g1sys/2009/07/csql-bbbb.html
にある、トレードオフで「顧客に対する影響」と「技術者都合」とどちらがどの程度大きいと考えますか？
RDBMSは基幹システムであれば、ほぼ商用のモノを高いライセンス費用を顧客に負担してもらっていることについて、どうお考えですか？
私の答えとしては、テーブルのバージョンダウン、アップ（つまり変更）が起きた場合、SQLにロジックがあろうと、言語にあろうと影響範囲は同じです。
テーブルの変更がないとき、SQLにロジックがあろうと、なかろうと、バージョンアップ、ダウンの影響があるような構成になる理由が分かりません。
それが問題になるなら、管理の方法が悪いのでしょう。
下手糞は無限に下手糞ですから比較対象になりません。
酔ってるので、問題があれば、明日、追加するかもしれませんが、名無しさんであっても、もし、プロとしてのプライドがあるなら反論がほしい。
同じ技術で喰ってるプロが、こんな言い捨ての意見を書いているとしたら本当に悲しい……。
toanna
あ！
> 逆にDBは変わらないのだから、スケーラビリティをあげるためにも、
> ロジックを極力DB側に詰め込むべきだと思いますけどね。
これは目から鱗ですね！
きっちり脳に詰め込みました。
toanna
↑
顧客へ説明するにあたり、最も効果的な決め台詞に感じました。
そりゃ速度も非常に重要だけど、
「継続」って単語は、不景気な現在には最も甘美な囁きのひとつですよne。
訪問者B
> あなたは、数ある設計書のバージョン管理をどのように行っていますか？
設計書はすべて、Wiki とそれに対する添付ファイルという形式で管理しております。
ストアドプロシージャを使用した場合と何か関係があるのでしょうか？
> あなたはVB6から同じベンダーの.NETに移行するに対しての大騒ぎをどのように感じますか？
大騒ぎと言われても・・・
そんなに大騒ぎになっているんですか？
自然に移行していると思います。
> 逆に、RDBMSでバージョンアップに対してどれほどの差がでましたか？
？
何を言っているのかがわからないのですが、RDBMSをバージョンアップしたことによるパフォーマンスの向上とかですか？
あまり感じたことはありません。
もしかして、バージョンダウン云々の話を誤読されてませんか？
RDBMSをバージョンダウンするという意味ではなく、ロジックをバージョンダウンというか、元に戻すという話です。
RDBMSではテーブルの状態やデータを含めてバージョンダウンする必要がありますけど、そういうことは現状では手軽にできませんよね？
その辺をどのように管理しているのかがお聞きしたかったのですが・・・
> その差が出たとして
"その差"が何を言っているのかよく分からないのでノーコメント。
ただし、表はおかしいと感じます。
SQLには精通しているようですが、OOについてはあまりという印象を受けました。
下の方の表はそれを如実に表していると思います。
工数やパフォーマンスは固定的にSQLが優れているとは言えません。これらは要求に強く依存します。
例えば帳票のフォーマットなんかはSQLでやるよりも言語側でやった方がはるかに容易ですよね？
保守性は見てもらえば分かるとおり、言語側に利があると考えております。
習得難易度については、単純に比較できるものではないと考えております。
"「HAVINGを使ったことがない」「EXISTSは良く分からん」"という方がRDBMSを使ったシステムの設計をしているのはさすがにどうかと思いますが、あなたについても"本当に「オブジェクト指向言語なんて」って心の底から思っている困ったチャン"だと感じます。
ただし、ブログという形にして発信しているため、確信犯で悪意があり、なおタチが悪いのかな・・・と。
> RDBMSは基幹システムであれば、ほぼ商用のモノを高いライセンス費用を顧客に負担してもらっていることについて、どうお考えですか？
話がどうつながっているのか全然見えないのですが・・・
"だから活用すべき"ということが言いたいのでしょうか。
仮にそうだとすると、それは少し暴論だと思います。
ライセンス料というのは見積もりは容易ですが、システムのメンテナンスというか、継続的な開発というのは見積もりは容易ではありません。
そのため、できうる限り改造が行いやすい状態を保っておくべきであり、その点でロジックをDB側に格納することに不安を覚えます。
ただし、基幹システムのようなシステムは関与したことがないことを付け加えておきます。
>私の答えとしては、テーブルのバージョンダウン、アップ（つまり変更）が起きた場合、SQLにロジックがあろうと、言語にあろうと影響範囲は同じです。
やっと本題ですね。
上でも述べたように、影響範囲は同じではありません。
現状では言語側にロジックがあった方が管理しやすいというのは、認めなければならない現実です。
> それが問題になるなら、管理の方法が悪いのでしょう。
いや、ですから、"自分には管理方法が思いつかないくらいどうしようもないと思っていることなのに、どうやって管理しているんだろう？"ということを聞いたのです。
問題点として、
0. ユニットテストの自動化と管理
1. ITS/SCMとの連携
2. リグレッションテストの自動化(これは実は0と同じ)
3. バージョンダウン(RDBMSのバージョンダウンではなく、ロジックのバージョン)
があり、これはすべて「技術者都合」が直接「顧客に対する影響」につながるものです。そこにトレードオフはありません。
> 同じ技術で喰ってるプロが、こんな言い捨ての意見を書いているとしたら本当に悲しい……。
言い捨ての意見のつもりじゃなくて、単発の質問のつもりだったのです。
にゃん太郎
生島さん、おはようございます。
言ってる事は激しく同意。特に、
> × 複雑なSQLは遅い
> ○ 下手糞に書いたSQLは遅い
これ。
私の経験上、前にも書きましたがSQLをデータベース読み書き言語程度にしか認識していない人が多いと思います。小規模ならそれでも良いと私自身は考えていますが（あまり速度や工数に差が出ないので）中規模以上や今は小さくても大きくなる可能性を秘めているならもう少しRDBMSの事を真面目に考える必要はあると思います。
何か問題（パフォーマンスなど）が発生した時、テーブル構成やSQLから逃げる人が結構いるんじゃないでしょうか？これはあきらかにRDBMSのスキル不足で、言ってしまえば見ても分からない（設計やSQLには問題ないと思っている、または思い込んでいる）からプログラムを見直そう、みたいな感じになってる気がします（経験上）
OracleにしてもSQL Serverにしても市販の本で（個人で買うには高いけど）内部動作やどの様に設計するのが適切なのかガイドライン的なものは割とパブリックに公開されています。そう言うのを知らずしてやれテーブル設計だSQLだとやるからおかしくなるような気がします。もっとも知らなくても動くのとソフトウェア雑誌でも「手軽にデーターベース」みたいな記事が増えているからだと思ってます。手軽に出来るのは良いと思いますが、それは手軽に扱える事と同じではありません。
プログラム修正はプログラムだけで済む事が多いですが、データーベース（テーブル設計やSQL）は下手すればプログラムや画面レイアウト（特にASP.NET）にまで及ぶ可能性があります。そう言う意味でSQLだけではなく、DBについては上流からしっかり考えて設計する事が重要ではないのでしょうか。
テクニカルな設計手法やテスト方法なども大事ですが、それは基本がしっかりした上での話でしょうね。趣味なら何も問題ないですが、プロのエンジニアなら「動くからOK」だけでは失格です。オブジェクト指向も良いですが、それ以上に大事な事はたくさんある事を認識すべきです。下手な設計にバージョン管理なぞあってもなくても変わりません。
訪問者B
> にゃん太郎さん
> 下手な設計にバージョン管理なぞあってもなくても変わりません。
そんなことはないです。
ちょっと極論ですが、下手な設計にこそバージョン管理等が必要です。
そして、人間は*上手な*設計に一発でたどり着くことなど出来ないのです。
それに、上手な設計ならバージョン管理が必要ないかというと、そうでもないですしね。
> プロのエンジニアなら「動くからOK」だけでは失格です
同意します。
プロのエンジニアなら、「動いた後」のことも考えなければいけません。
そのためには、バージョン管理ツール等の導入は必須です。
いまや、バージョン管理ツールや課題管理システムなどの開発インフラの導入はシステム開発において必須のインフラとなりつつあります。
> テクニカルな設計手法やテスト方法なども大事ですが、それは基本がしっかりした上での話でしょうね。
> オブジェクト指向も良いですが、それ以上に大事な事はたくさんある事を認識すべきです。
あなたの言う"基本"とはなんでしょうか？
"それ以上に大事な事"とはなんでしょうか？
SQL/DBに傾倒しすぎている時点で、"基本"を見失っているような気がしてなりません。
システムはSQL/DBだけではまわりませんよ？
訪問者Bさん、どうも。
基本的に特定できない名前のコメントに返事するのは非常に苦痛です。
酔っ払ってたので、バージョンが何を指しているのか分からなかったのですみません。まだすこし宿酔いで……。
VB云々は、
http://el.jibun.atmarkit.co.jp/g1sys/2009/06/post-228b.html
びっくりするほど燃え上がりました。世の中はこの程度で大騒ぎするらしいです。
DB側にロジックを持たせるということは、普通はストアドプロシージャにするでしょう。それぞれプレーンテキストでファイルに保存して、そのバージョンを管理することになります。
テーブル構造のバージョンダウンがあったら、そのバージョンに合ったものを流せばよいのでしょう。
ドキュメントのバージョン管理ができるのにソースのバージョン管理ができない理由が理解できません。
ツールがなかったらできないというのも、技術者としてどうかと思うし、必要と思えば作ればいいと思います。
テーブル構造は簡単に変えれないからこそ、DBにロジックを詰めてと……。
よろしければこちらもご覧ください。
http://el.jibun.atmarkit.co.jp/g1sys/2009/01/post-037e.html
こちらも読んでいただいたようですが。
http://el.jibun.atmarkit.co.jp/g1sys/2009/07/csql-bbbb.html
初級シスアドなんて数あるITの資格の中でもっとも保有者が多いものです。
エンドユーザに理解を求めているものの保守性が悪いという理由も理解ができません。エンドユーザに言語の理解は求めてないけれど、SQLについては気の毒なぐらいのレベルを求めているようです。
IPAの考え方が悪いのでしょうかね？
toannaさん、どうも。
私の知っているところで、情シスの担当者が新しい物好きで、COBOL → VB4 → Delphi → Java と変遷したところがありましたが、VB4のときにOracleを採用して、現在もOracleです。
Delphiからストアドプロシージャにしていましたが、Javaへの移行はかなりすんなりできたようです。
まぁ、ストアドプロシージャはワークテーブルを使うパターンだったので、個人的には納得できないのですけどね。
DB側はそう簡単に変わらないから、ロジックはDB側に入れた方が良いわけです。
SIerとしてパッケージを作るときは微妙ですがね。
にゃん太郎さん、どうも。
パフォーマンスの問題が起きたときに言語の方を見直してもほとんど解決しないでしょう。それで、工数をふんだくってくれる人はたくさんいるけど……。
私は一応社長で、基本受託なのでそんなことをする奴は許せないのね（苦笑）。
パフォーマンスの問題が出たときにハードのせいにしてメモリーを積めば云々って言って、init.oraが……。
Oracle8以下のときの未チューンのinit.oraはすごかったからな～。
これでx年も運用してたの？詐欺だ！
と何回も思った。
okaa さん、どうも。
なんというか、1日かかるクエリというのが想像できないというか、できるというか。
儲けてナンボですがね、1日かかるクエリは、たぶん、作り直したものの数倍以上の工数を掛けて作ってますね。
人月ビジネスなら、「1日かかるクエリ」を作った方が儲かるのです。
こういう構造をぶっ潰してやる！って思っています。
にゃん太郎
訪問者Bさん、はじめまして。
> 下手な設計にバージョン管理なぞあってもなくても変わりません。
極端ですよねぇ、これ。いやいや、これが乱暴な言い方なのは自分でもわかってますし、必要なのも理解しています。言いたいのはプロなら下手な設計（この場合の設計は上流を指します）するな、って事を言いたいだけです。上流であかんかったらそれ以後、何やってもダメになる可能性が高い、と言いたかっただけです。100%ダメとは言いませんが、ダメなモノを管理してもダメと言いたいだけです。
> あなたの言う"基本"とはなんでしょうか？
> "それ以上に大事な事"とはなんでしょうか？
本当はそれを考えて欲しいんですけど、最近のエンジニアはすぐ答えを欲しがりますね（あなたが若いかどうかは分かりませんが）
上っ面だけの技術ではなく、もっと根本の技術を知って欲しいと思います。コンピューターであればOSがどの様に動作してハードウェア（CPUやメモリ、デバイスなど）はどの様に処理をしているのか？ネットワークであればプロトコルやレイヤーの動作やどの様に処理して通信しているか、RDBMSなら内部でどの様にデータを保持・検索しているか、どの様にデータの追加を行っているか･･･などです。昔と違い、複合的に動作していますが所詮、個々の技術の組み合わせになります。これらを知っているだけで相当手戻りやプロジェクトの失敗、トラブルの早期解決（これが一番）が出来ると私は思います。
あなたがどのようなスキルを持っていてどのような経験、経歴、年数を経た方かは分かりません。私が述べた事も知っているのか知らないのかも分かりません。いや、別に知りたい訳ではないのですが。
私もおそらく生島さんも
> システムはSQL/DBだけではまわりませんよ？
こんな事は充分すぎるほど分かっていますし、そんな事一言も言っていません。それが読めないのであれば
> SQL/DBに傾倒しすぎている時点で、"基本"を見失っているような気がしてなりません。
と言う資格はないと思います。
私自身は別にDBにロジックを入れる/入れないと言う議論はあまり興味がないです。ケースバイケースでどちらでも構いません。経験上は詰め込んだ方が良いと思いますが。確かに生島さんのコラムでは傾倒しているように見えますが（笑）逆に言えばDBの事を本当に知っている人が少ないのかな？と思っています。まぁ知らなくても何となく動くし、ソフトウェアを作る事自体、安く、簡単に、それこそ本屋で入門書を買ってこればたいていの人はかんたんなソフトは作れますから、私のようなオヤジの言ってる事は戯言だと思っているのかも知れません。
別に生島さんの肩を持つ訳でもなんでもないのですが、バージョン管理やオブジェクト指向が大事なのは分かってます。でも、
> DB側にロジックを詰め込みたいとのことですが、構成管理上あまり嬉しくない気がし
> ます。
> DBはある意味バージョン管理や継続的統合との相性が悪いと感じており、ロジックを
> DBに持たせたくないというのがあります。
こうおっしゃるならプロとしてDB側にロジックを入れる事の不都合を書いた方が良いと思います。「嬉しくない気」や「相性が悪い感じ」だけではプロとしてどうかと思います。私には「自動でテストが出来ないから面倒だ」としか読めません。バージョン管理なんて大昔からあり、それが最近は便利になってるだけだと思います。バージョン管理ツールや課題管理システムは便利なのも分かりますし、使うなとも言いませんが（私も使っていますし）必須ではないと思います（いや、管理は必要ですよ）おっしゃる事の正当性は理解出来ますが、それが「DBにロジックを入れるべきではない」というプロとしての反論になっていないのが残念です。
あぁ、生島さんのコラムなのにまた長々と･･･（ごめんなさい）
インドリ
元々DBMSとDOAはトランザクション正規化と制約条件チェックの重複を排除する方向性で物事を考えます。
ですから、なるべくDB側に制約条件チェックを記述するのは原則です。
そのために、トリガーとストアドプロシージャが出来たのです。
ですからDOAをやるのならばDBMSやSQLの学習をして欲しいというのは当然だと思います。
amiga
えーと、ここで論議されているSQLとはストアドなのでしょうか？
DBに入れるって所から察すると、VIEWっぽい気もしますが…
（この時点で対象外か…）
多分ここの人たちは判っておられるとは思いますが
同じ製品のDBでもアーキテクチャーが変われば
今まで好しとしていた書き方が悪くなるって可能性もあったりしますから
極論を言えば、どっちもどっち
（ホントに極論ですよ）
私的には可読性を求める方なので、余程処理にシビアさが求められない限り
あまり複雑なのは書きたくない方です
と言うか、近々はドキュメントを作らない（作る工数が無い）仕事が多かったので
他人の作った途方に暮れるくらい長い構文があったりして
変更をかける時に「こんなの読めるかよー、これならストアド組めよー」と…
（もっとも、ストアド組む工数も無いので 無理なのはわかってるんですけど）
ただOracle 9iの時、初めてストアド使いましたが
デバック大変だったけど結構使いやすくて、当時バンバン使っていましたし
「スピードアップには、これはキクなぁ」というのは身にしみてわかりましたねぇ
私的な理想も
DB[ストアド等でデータ取得･書込を全て処理]･AP[その処理] と言う所ですね
よほどのプロジェクトじゃなければムリですが
#にゃん太郎
>本当はそれを考えて欲しいんですけど
>最近のエンジニアはすぐ答えを欲しがりますね（あなたが若いかどうかは分かりませんが）
お気持ちは良くわかるのですが、こう周辺が複雑化している現在
調べてる時間が勿体無いと思うのですよ
今はネットである程度は出てきますし、少なくとも聞きにくる時点で
自分に出来る調べかたはした上で、答えが出なかったのだろうと思っています
「どうせ苦労するなら、オレの知らなかった事で苦労してよ。わかったら教えてクレ、盗むから」ですね（笑
saki1208
saki1208です。
自分で調べる時間は決して無駄にはなりませんよ。
調べるという行為その物がエンジニアとしての地力
を作るのです。
調べもせずに聞いた事は必ず忘れます。
インドリ
VIEWならばよりなおの事です。
あれは分かりやすいまでにDOAの考えを反映しています。
未だにDOAを氏がちな上流が、ソフトウェア工学をちゃんと学んでいないのは酷すぎますね・・・
データベースをちゃんと学ぼうよ！
oumi
元記事とはほとんど関係ないですが、
訪問者Bさんが言うような観点は、正しいと思います。
構成管理上の話っての。
前にも言いましたが、訪問者Bさんが言うような、構成管理上、DBに業務処理をいれていくと大変なことになるってのは本当ですよ。これは、量と仕組みに密接な関係を持つ問題でもあるので「そういった匂い」と抽象的になってしまうのでしょう。
技術者なら作る。それは正しいが、間違いでもある。そのコストを誰が負担するかっていう話がありますからね。
ストプロが何万もあると考えたらぞっとします。力技で管理できる状態じゃなくなりますもんね。そして今のところ、DBのオブジェクトを効率よく管理できるソリューションって無いようですから。作るにしても誰が負担するの？ってなりますね。
（テストやバージョニング含めて、作ったら売れそうだけどね）そして、こういったソリューションの問題は、ＤＢに閉じてしまうと魅力が薄れるって事かな・・
たとえば、ある変数の型を変えた場合、ストプロやViewを始めとして、DBのオブジェクトの中までトレースして影響範囲を洗い出す、なんていうことができるソリューションがあるといんですけどね。聞いたことがないんだなこれ。
ないから管理方法で？は冗談すぎる。何万本もあるんですよ・・
（同時稼動バージョンを考えるとその３倍とかある場合も）
そしてできるなら、アプリの場合と統合した使い勝手が望ましいですからね。
開発局面では、これが複数の同時進行している開発バージョンに対して行われる必要があるわけだ。
作り手側の都合って言う面もありますが、ＥＵ側の問題でもある。資産の管理運用をＥＵがしていかなければならない事も多いですからね。
構成管理の問題は、ボディブローなのです。
MSのチーム開発は、ここまで突っ込んでできるんだっけな？
最近ウォッチしてないのでわからないです。
後、DBに入れてしまうとテストが大変になるってことがあるのも本当。テスト内容ではなくて、テストの運用なんかだね。
単純なデータストアとして使われている場合は、複数のテストプロジェクトが同時進行しても、ネットワークトラフィックで若干問題がある程度。でもDBそのものとアプリの関係で問題がでるってことはあまりない。
ところがDBに業務処理が多量にのっかるととたんに出てくる。主に、DB側リソース関連だね。これも、数本のテストプロジェクトが同時に走る程度だとあまり発生することじゃないんだけども・・
このようなことを言い出すと多々あるけども、それを全部ここで言うわけには行かない。なぜなら、物量に絡むノウハウは、まんま個人・SIerのスキルだから。（良し悪し２面あるけども）
こういった、開発期間の問題もEUの問題でもあるのだ。なぜならこのコストを出すのはEUだから。
ってことで、入れられるものすべてを入れれれば良いってもんじゃないと思うのです。
さじ加減が大事で、そこはSIer以下の腕の見せ所でもあるのです。
できるなら「データ集計」をDBに入れよう、いれたほうがいい（事が多い！）でしかないと思う。
ちなみに、構成管理の問題は、稼動後も大きな問題ということで、Bさんの肩を持った。むしろ、SQLがどうのこうのよりも、稼動後のさまざまな運用を気にしない（話題にしない）上流のほうが問題だな。
総じて、私はDBに業務ロジックは入れさせない派です。
Viewも当然使わせない。
DBは、構造化されたデータ・ストアと考えている派ってことです。単なるSAMの延長でもなければ、理想的なRDBでもないその中間？
経験的な話で根拠はありませんが、この構造化されたデータ・ストアって考えてオブジェクトを用意してくのが、中庸で良いという感じです。良いってのは、SQL飛ばしでもストプロ用意でもどっちにも都合が良い感じ。
性能も悪くない。データも変に重複・分散しない。意外とO/Rにも向いているし、.NET のDataSet Object にも向いている感じ。
逆に、ストプロ無しで作って性能だせないシステムって・・・それが問題じゃないか？
です。もちろん、ガチガチのチューニングが必要でストプロ使うことはあります。
DBに集約するもしないも、程度の問題だね。ってのはそのとおりですね。
VB6 vs VB.NET の話題に酷似している気がするな。様相がですけど。
>未だにDOAを氏がちな上流が、ソフトウェア工学をちゃんと学んでいないのは酷すぎますね・・・
これそのとおりと思う。
前にちょっとインドリさんに突っ込んだコメントで「教育を含めての問題だ」なんて言いましたけど、まさにそうなのです。日本では教育機関で「ソフトウェア工学をちゃんと教えていない」なので、未来に登場する若手がグローバルに勝負しようとすると基礎から負けちゃうんだよね。
独学で苦労できる人も少ないだろうし・・
ましてや、４０過ぎてしまうと・・・・まず無理（ｗ）なぜなら脳の働き方が若いときと年寄りとでは変わるから。「深く」よりも「広く」に向いた脳の働きになるようです。
いい加減、教育現場がバブリーな(COBOLERな)時代を抜け出さないとね・・
まぁ、生島さんは同年代あたりを救いたいのかもしれませんが？
私は、切り捨てて、若者に期待しますね。自分が切り捨てられるかもだけど orz
oumiさん、どうも。
レベルの低い話をするとですな、OOで完全に単純なSQL（JOINすらなし）を書いているとすると、確実にパフォーマンスの問題が起きるでしょう。
JOINを書いているとすると、テーブルは一ヶ所にはまとまってないはずです。
OOで管理しているSQL文はDBMSから見れば単なるSTRINGに過ぎません。
テーブルが変わった場合、どこで使われているかは動的SQLを解析しなければ分からないってこともありますね。
本当に動的に組んだSQLのStringを引数にしてたりするのがあって、もう、追いかけれなくって泣きそうになることもある。
きっちりとCRUDが管理できていればよいのですが、できてなければ悲惨なことになります。ストアドプロシージャになっていればテーブル構造などに変更があれば、関連項目はすぐに分かります。
依存関係はライブラリを見れば分かりますし、相関図を作ってくれるツールはいくらでもありますね。
バージョン管理は、VSSでも、CVSでも、SubVersionでもいいじゃないですか。
.NETなら、VSのプロジェクトにSQLというフォルダを掘って、そこにSQLファイルを入れて管理するのもよいでしょう。
秀丸マクロでもSAKURAエディタのマクロでも、やろうと思えばできます。
要は慣れだと思いますよ。
End Of Fileさん、どうも。
おっしゃるとおりで、O/Rマッパーなど最低ですよね。
SQLができない前提で、目的は、できない人が曲がりっぱなしのシステムを作れるという代物ですからね。
OOAがすべてという人は、SQLを覚えたくないが目的化してるからな～。
両方必要だと思いますよね。
できない人に合わすことが目的化したら駄目ですよね。
ほんとにヘボが多いから、仕方なく手段としては選ぶことがありますよ。
逆の話でしょうか？
近江
生島さん みなさん どうも。
ちなみに、SQLがよろしくないとは言ってないですよ。むしろ大いに賛成してますよ。（極端な話）全てのSQLをストプロに押し込めるのが、構成管理上気に入らんって言っただけです。
デフォは、SQL Server (最近こっちばかりで・・)ですと、パラメタライズドクエリーで、って事かなぁ。初回のクエリ解析～コンパイルのコストが気になる場合は、ストプロにせざるをえないですね。
最初から、ガチガチにチューンナップされていると、何か問題あったときの余裕が無いので、それこそ、直ぐにスケール○○ってなっちゃうし、出来る限り、想定範囲内での性能をキープしてなおかつ、ノビシロを確保したいって気持ちがあるんですね。
ある意味、
SQLステートメントのチューニング
SQLステートメントの永続化
は、比較的に手軽にできて効果の大きな方法でもあることですから。
技術者なら最高のパフォーマンスを出すのは当然だろ！
なんて言われると、そうですねー、って言うしかないんだけど、
「限定的対象範囲の最大パフォーマンスは、長期にわたる広い対象範囲のパフォーマンスを保障しない」なので・・
パフォーマンスにもリソースにも改善の余裕が無いと（判っていないと）危なくてしょうがないでしょう。
kim
生島さん。
いつも興味深く、拝見させて頂いております。
私は、
ＤＢ＝データストア＋業務ロジック（ストアドプロシージャ）
と考えております。
販売管理システムで考えると、
「複数商品を倉庫から出荷した」＝「複数の売上計上」＋「複数の倉庫在庫払出」
で１トランザクションです。
クライアント／サーバ型システムを想定します。
これをＵＩ側（ＶＢ側）でＤＢ更新することを考えると、
ＤＢサーバとクライアントＰＣで、
複数回のピンポン通信が発生します。
これがストアドプロシージャでＤＢ側で実装すると、
１回の通信で終了します。
通信速度的にはストプロ実装方式の方が遥かに早いです。
コードレビュー、テスト工程やデバッグについても、
ストアドプロシージャ内で何のテーブルが
・排他ロック
・参照
・更新
されているか、目視しやすいです。
Oracle8iから実装された一時表や自律型トランザクションといった機能が
ストプロの可能性を大幅に広げたと実感しております。
現状の私の結論としてましては、下記の通りとなります。
・業務ロジックはストプロで実装しましょう。
・ＵＩ側（ＶＢ側）は画面制御に徹底しましょう。
・基幹システムはＣ／Ｓ型がやはり主流です。
以上です。
近江さん、どうも。
後でネタにさせてもらうかも知れませんが、将来のバッファを残すというのは違うのよね。
イヤ、現実的には正しいし、その現実的な正しさは私も分かっているのですけれど…。
パフォーマンスのバッファーを残すというのは、つまり、簡単なSQLで処理した方が工数が少なくなるとき成り立ちます。
つまり、C言語とアセンブラの関係ですね。
この感覚は難易度をどう捉えるかによって違ってくるのでね……。
くどいけれど、後で書きますけれど、工数って、
工数 ＝ コーディング量 × ツールのでき × 言語の難易度 × 習熟度
で、「コーディング量」、「ツールのでき」、ぐらいは本来固定であって欲しいのですけれど、スキルによってかなり変動しますよね。
そのほかのパラメータはもう、個人依存度が高すぎて、実は全うな議論になってないと思うのです。
で、私の新たな基準は初級シスアドの問題で、初級シスアドであのレベルなら、他の人たちはどうも、パラメータを大きくしすぎじゃないかなと……。
虚人
SQLもオブジェクト指向も初心者と熟練者のレベルの差がてきめんに現れますよね。
私自身、”SQL最高ー！”っていう気もありませんし、”オブジェクト指向絶対！”っていう気もありません。
O/Rマッピングについては目の前がクラクラするので、言及できません。
あれは…なんかアプローチが間違っているような気がします。
世の中の”流れ”として、SQLは黒子の役割ですよねぇ～。
SQLの玄人はいますが、大勢ではないので。
商業活動として、それはそれで仕方ないのかな？
会社には、オブジェクト指向やSQLの教育コースがありますが、オブジェクト指向の方が断然人気がありますね。
世の中の流れがそのように仕向けているのでしょうかね？
SQLオーソリティは絶滅状態にあるので、今後はオブジェクト指向屋さんが台頭してくるのかな。
品質保証屋のたわごとでした。m(_ _)m
oumi
そもそも、構成管理とか、将来的なバッファだとかって観点が違うのか。
>工数 ＝ コーディング量 × ツールのでき × 言語の難易度 × 習熟度
この式だと、システム全体を指しているわけではなく、粒度が全然違う話ですもんね。
どうも、話のモデルが定まっていない感じで、うーん。
システム開発では無くて、アプリケーション開発ってことなのかなぁ・・
構成管理上ストプロがよろしくないって、そんなに問題あるんだろうか・・
しごく普通と思ってたんだけどなぁ・・
現実、問題あるんだけどねぇ・・・簡単にうまく伝える言葉が見つからんねぇ
もっとも、「１世代あたり５万本～１０万本ものストプロをうまく構成管理できているっていう、現実がある」ってだれかが言ってくれれば、「へぇ～、ちょっと考えなくちゃ」って素直になれるのですけどね・・
「はずだ」「慣れだ」じゃ、ちょっと信じられないな・・
せっかくだから、ストプロ反対の線を推し進めることにしてみる(W)
※SQL反対とか、完全にストプロ排除とかじゃないので、お間違いないように。
一時テーブルだぬ。こいつがとんでもなくだめだ。
システム開発当初からDISK追加は動的にやる約束が出来ていない限り、DISKの玉を追加するだけでも、大変結構な騒ぎになる。
で、ストプロ解放したとします。さて、そのシステムで一時テーブルがどれだけ使われるのかを、誰がどうやって見積もるのでしょうか？答えは「方法無し」です。
アプリケーションの場合も同じだろ？実は違う。アプリの場合は「遅い」けどおバカなループで間に合って(しまって)いることも多い。そして、SQL使いはシステム全体なんて見ようとはしないのです。問題は、方法・実現性、とかそんなことじゃなくて、「見積もれない」って事なのです。この糞一時テーブルは、ほんのちょっとした条件の差異でベラボウにどが～んとでかくなったりするわけで、むかつく～！なのです。
そして、なぜか？その小さな条件の差異が事前に予測される事はないのだ orz
愚痴だと思うなら、まぁそうかもしれない・・・
oumi さん、どうも。
「とりあえずビール」じゃないや、「とりあえず単純なSQL」でというのは、単純なSQLの方が工数が少ないときに成り立つ話じゃないですかね。
昔、アセンブラは最後の手段としてとっておいて、C言語でとか、C++は最後の手段として取っておいてVBでとか、ありましたけれどそれって最後の手段の方が工数がかかる例ですよね。
工数が逆転していないのであれば、トレードオフの関係はないのです。
ストアドプロシージャにしたらワークテーブルが増えるというのは、私にはないのですよね～。
弊社で中小企業（年商20億程度）の基幹システムリプレースしました。PostgreSQL、C#の案件でしたが、すべてストアドプロシージャで作りました。
SELECTを含めC#から生のSQLは一切禁止でやりましたけれど、一時テーブルはゼロです。
場合によっては使っても良いのですけれど、セッションIDをキーにしてワークテーブルに突っ込んで、クライアント（AP）側でセッションIDで抽出するSELECTを書く。
ってパターンも見なくもない（というか、かなり多い）けれど、それは勘弁して欲しい。
ワークを使った方が効率が良くなる場合もあって、その場合は使うけれど、実テーブルで作るのは最低でしょう。（まぁ、テスト中は実テーブルの方が良いのですけど）
ストアドプロシージャ講座も暇になったら書こうかな。
虚人さん、どうも。
O/Rマッパーは中にすごいのがありますよね。毎回全件取得して読み飛ばすってものすごいプログラムを見たことがあるけれど、件数によっては1日が1秒になりますな。私の場合、件数がそれほどでもなかったので2時間が1秒でしたが、2人月掛けたプログラムをまるっきりやり直しても数十分という工数でした。
2人月の請求を出すって、もう、詐欺以外の何モノでもないと思いますけれど、それがまかり通るのよね～。
> 世の中の”流れ”として、SQLは黒子の役割ですよねぇ～。
> SQLの玄人はいますが、大勢ではないので。
> 商業活動として、それはそれで仕方ないのかな？
おっしゃるとおりですけれど、私は、「流れを変えてやる！」って思っているばか者です。
たとえば、アセンブラは達人であってもCの工数は超えれない。
SQLは達人になれば他の言語の工数を簡単に超えられる。
あとは「達人になれば」のなるためのコストがどれぐらいかかるかというところが問題になりますが、本当はOOよりも少ないコストで可能なんですけどね、これが伝わらない。
難しいな～。
SQLですべてが終わるわけではないのですけれど、終わる部分は終わらせるべき。
ということです。
虚人
お返事ありがとうございます m(_ _)m
> おっしゃるとおりですけれど、私は、「流れを変えてやる！」って思っているばか者です。
いや、その心意気は大事だと思いますよ。
SQLの威力はよーく知っています。
その威力をアピールできていない（する人が居ない？）のが、SQL低迷期（周りの状況からそのように判断）の原因ではないかと思っています。
良いものは良いし、使わなければ損ですからね。
しかし…本当にSQLの達人は減りましたねぇ。
どう考えても素人が作ったSQLは、玄人のSQLにかないません。
ただし、闇雲にSQLで構築したために、その後にSQL保守人を確保できず、やむなく全部作り変えの目にあったプロジェクトも多数。
かくいう私は、品質改善にぜんぜん理解の無い人たちに「品質改善だぁぁぁ！」って言い張っている”ばか者”です(笑)。
ちゃんと後々のことまで計画してね、っていうのが私のスタンス。
”うちの開発プロセスなら、軽くCMMIのレベル３は堅いよねぇ～”なんて言っている世間知らずに、身の程を教えてあげるのも私の仕事(笑)
oumi
ストプロ反対ネタも、尽きた・・・
管理・変更・テスト・一時、これ以外には、特にこれという理由が見当たらない・・
もう人がいないとかそんな理由しかないかな(W)
ちなみに私が想定している規模は、今年の営業収益見込みが4兆円強くらいの企業。微小なブレがべらぼうな事になります。
> 今年の営業収益見込みが4兆円
うそ～。トヨタの最高益でもそんなに行ってませんぜ！売上でしょう。
でね、その規模なら、教育した方が安いって言ってるのですけどね。
そのプロジェクトで確実に回収できますよ。
上が理解できたら教育するはずが、スタートラインでつぶしているわけです。
だから上流ってグルグル回るのですね……。
虚人さん、どうも。
> ただし、闇雲にSQLで構築したために、その後にSQL保守人を確保できず、
> やむなく全部作り変えの目にあったプロジェクトも多数。
多数ですか！
もったいないというか、なんというか、作り変えるコストで教育できると思うけれど……。
oumi
営業収益ですよ営業利益じゃなくて。
>ただし、闇雲にSQLで構築したために、その後にSQL保守人を確保できず、
>やむなく全部作り変えの目にあったプロジェクトも多数。
これが怖いのですよ（＞＜）
まぁ人がいないって事になっちゃうんだけど・・
虚人
To:生島さん
＞作り変えるコストで教育できると思うけれど…
今後の事業戦略（そんなものあるかどうか？ですけどね）によるんじゃないでしょうかね。
人材ポートフォリオなんていう事が耳に入っているかどうかは別ですが、どんなスキルを持った人を何人確保する、とか。いろんな理由でSQLの達人は伝説になろうとしています。
それでも、Oracleマスターは何人か存在していますよ。ゴールドやプラチナのね。
でも、悲しいかな。彼らのところにはアーキテクチャを検討する仕事はまわってきません。
To:oumiさん
SQL人を育成しないのなら、買う（？）というか雇うしかないのですけど。
最近は、Webで簡単に質問できたりする（ちゃんとした契約を結んでいたりする）ので、わざわざSQL人を抱え込む必要はないと考えているのかもしれません。
でも、コンサルは提案をするかもしれませんが、自分で実装してくれません。
初心者SQL人では、そもそもSQLで物事を解決しようという発想はありませんから、自然消滅なんでしょうねぇ。
利益に見えて勘違い失礼。
つまり、初級シスアドレベルも出来ない人が上流にいて、上から潰してるってことに尽きるのです。OOとか言語周りの技術が伸びるのは、下から突き上げたら変えれるし、その方針が変わったところで最上流は全く影響しないから、下流が普通に努力すれば延びる。
この事象をもって、上流は言語は関係ないと言えばそのとおりなのです。しかし、SQLは本当に最上流で決まってしまうのね。
初級シスアドのSQL講座みたいなのを見ると、初級シスアドって本当に学生とか、OLさんとかがスキルアップのために受けてたりする素人向けの試験で……。
どこまで行っても、やっぱりSQLの難易度の見積りが高すぎることが原因だと思う。
慣れないととっつきにくいのは分かるし、どこかで過去の自分を大きく否定しないといけないしね。
難しいものです。
test
SQLなんて全然複雑だと思わない。
集合処理に向くものなので、構造化言語の頭で考えると
読みにくいかもしれないけど。。
また何の技術を使用して、要件を満たすかは要件次第
ロジカルな要件には、構造化言語の方が保守効率は確実に高い。
江戸紫
はじめまして。
達人には程遠い中級レベルのSQL使いですが、
生島さんのご意見に賛同するところが多くあると思いながら読んでました。
DB側に業務ロジックをシフトするのも基本的には大賛成です。
ただ、以前、結構複雑なSQLのバッチ処理を書いたところ
数十回に１回の割でDB側のバグで結果を正しく返さないことがありました。
手続き型言語のように確認しながら進めることができないので
「ここでおかしくなってる！」とつきとめることもできず
なかなかベンダーを認めさせることもできずに相当苦労しました。
（お客様が、責任の所在を明確に追及するところだったので。）
もちろん言語のコンパイラにだってバグはあるでしょうけど、
幸か不幸か今まで直面したことはありません。
大局的にはDB側にロジックに賛成にですが、
DB製品の質に若干懐疑的なところがあり、
そのDB製品に依存してしまうところが唯一弱点かなぁ、と思っています。
江戸紫さん、どうも。
数十回というか、もう少し頻度は少なくいような気もしますし、言語側と比べるとはるかに頻度は少ないですけれど、絶対ないかというとありますね……。
バグがあったときの破壊力は言語側に比べると大きくなるので困りますね。
もう少しユーザ（DB側にロジックを書くSE/PG）が増えると、それだけ完成度が上がりますから、そういう方向に流れてほしいなと思います。
インドリ
>手続き型言語のように確認しながら進めることができないので
「ここでおかしくなってる！」とつきとめることもできず
プロファイラを使えばいいと思います。
私個人の経験では製品の問題（パッチが提供されないもの）に遭遇した事がありません。
製品側のバグと決め付けずに、ロック粒度などを検討すればいいと思います。
testさん、どうも。
> 集合処理に向くものなので、構造化言語の頭で考えると
> 読みにくいかもしれないけど。。
結局、これなんでしょうね。
COBOLもJavaも、ループや分岐の部分の考え方は同じですからね。
COBOLerからも変な言語、オブジェクト指向派からも変な言語って思うのでしょうね。
SQLでやりましょうっていう私に、結託して襲ってくるから私はなかなか勝てません。
インドリさん、どうも。
パッチが提供されてないものに当たったことは私もないけれど、パッチを当ててないのには何度か遭遇したな。
それでも、確率的に何十分の1というほど高くはないと思う。
ただ、Oracleのツールのバグは、もう笑うぐらいたくさんたくさん！
まぁ、あれはグリコのオマケぐらいにしかみんな見てないと思うけれど。
ゴット
みなさんホントに馬鹿ばかりですね。
そもそもストアドは必要あるから存在するんですよ。
特にパフォーマンスや開発効率といった点が重要なわけで、
ハードウェアとソフト開発にいくらでも予算と時間を確保できるなら別ですが…
あと、何でもかんでもＯＲマップとか言ってるヤツはＲＤＢＭＳがなんたるかも理解していないんでしょうね。関連するデータを集合として操作できることが最大の利点なのに…一行づつリードライトが楽にできて複雑なＳＱＬを知らなくても開発できるって？小学校から算数やり直せよ
某ベンダーＳＥ
ここで言われているようにＳＱＬやストアドは自分ができないからイヤという、およそプロとは思えない言い訳を言うヤツらは、結局のところプログラムでやらせてもコーディングレベルは例外無く低いです。ＳＱＬあるいはストアドなら数行できることを、長々とプログラムで書いてそれでバグだらけだったなんてことがよく見受けられます。
ゴットさん、某ベンダーＳＥさん、おはようございます。
ORマッパーはほんとに要らないね。
存在自体が邪魔で仕方がない。
SQLは業務理解が理解できていたら、頭の中ではできているのですけど、それをつぶしてバラバラにしてレコード単位の処理に置き換えている。
それが無駄だといってるのですけれど、何とも怖いらしいです。