>RSSベンチャー社長で技術者で株式会社ジーワンシステムの代表取締役。新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。Serverも、Oracleも、フリーのPostgreSQLも、RDBMSとしての本質的な性能差は本当に小さい。そのためRDBMSのベンダーを選択するのは、バックアップとか、レプリケーションとか、クラスタリングなどの機能や関連ツールのできと、IDEとの相性などを検討するのが良いでしょう。一般的にあまり検討の対象になってない部分が、実は一番大きな違いだったりします。ServerとOracleの差で、もっとも大きいのはストアドプログラム(プロシージャ・ファンクション)の書き方(構文)の違いだと思います。単純なロジックはOracleの方が書きやすい。書かないといけないのは、大概勘弁して欲しいと思います。Serverを推しているのは、SELECT系のストアドプログラムが圧倒的に書きやすいから。逆にOracleはSELECT系のストアドプログラムが書きにくく、Oracleが圧倒的なシェアを持っていたころに経験したSEたちに、「ストアドプログラムはバッチのためにある」という誤解を持たせてしまっています。繰り返しますが、OracleではSELECT系のストアドプログラムは滅茶苦茶書きにくいです。具体的には、いろんな方法があると思いますが、基本的には次の3種類ではないかと思います。データ型の引数に戻すフレームワークが対応していなかったりするし、テストが簡単にはできないPL/SQL表を使うわたしはこのパターンを推奨というわけで、3.で書いたとします。パッケージにしなければもう少し短いですが。このコメントを削除する。できるようにして欲しいな~。このコメントを削除する。@PARM2;GOとなります。いずれも、実行時は普通のSELECT文と同じに扱えますから、この結果をO/Rマッパーなどでマッピングすると本当に工数は下がりますし(そこは否定したことはないよ)、以前から書いてきたように、画面はパーツを並べて活性非活性や色などの制御を顧客の気に入るように現物を見せながら調整する方が早いのです。アジャイル開発に向いています。そこをウォーターフォールでやってもかまわないけれど、とにかく、外部(UI)と内部(DB)を明確に分けた方が工数は下がりますし、顧客満足度も上がります。パフォーマンスも良いものになります。本当に、SQLを書く能力はプログラミング力の中でもっとも差が強く出ますから、無理して全員がSQLをできるようするのも馬鹿げているし、できない人に合わせて全体のレベルを下げるのも間違っているでしょう。◇それらは、またの機会に書くとして(まだ書くのか)、ソース量の違いもさることながら、Oracleは型や名前の整合性を取らないといけない場所があまりにも多いことが分かるでしょうか。弊社ではエクセルでジェネレートしています。ServerとOracleでは大幅に工数が変わります。Serverを推しています。経験は圧倒的にOracleの方が多いですけれど......。?ここでも、SQLServerの方がスマートです。わたしがこれまで書いてきたような、ストアドプログラムで分離開発するなら、SQLServerの方が工数削減効果は圧倒的に高いです。わたしは経験が長いからどちらでも一緒ですけどね......。ちなみに、PostgreSQLは、Oracleに近いけれど、もう少し簡単な記述になります。10:03SQLServerは複文が使えるのもありがたいんですね。同様の内容をそのままクライアントから実行できるので助かっています。10:39choirさん、こんにちは。いわゆる無名ブロックってやつで、Oracleでも使えますよ。いずれにしても、この辺の記述方法ではSQLServerに軍配が上がるかなと思います。12:15生島さん、こんにちは。ほうが気にいると思います。13:00エントリーポートさん、こんにちは。パッケージはやはり欲しい機能ですね。次善の策として、私はプロシージャをパブリック、ファンクションをプライベートとすると良いと思います。共通処理はすべてファンクションにする。コメントを一覧表示できるのと、検索が比較的やりやすいので、なんとかパッケージなしでも使えます。15:03>生島さんありがとうございます。帰宅したら弄ってみます。22:48生島さん、はじめまして。Serverが中心です。ServerがSELECT系のストアドが書きやすいというのは同感です。Serverのストアドは生産性が高いと思います。生島さんも書いているように、前の会社ではストアドはほとんどバッチ処理でしか使っていませんでした。Tableをまるでプログラムの変数のように使うストアドです。極端なサンプルですが、イメージ的にはこんな感じです。Tableに格納しながら結果を求めるのです。SQLに慣れていないプログラマはSQLで宣言的に結果を求めるより、変数を使いながら手続き型で考える方が考えやすいんでしょうね。手続き型で書いてしまうとデータベースによるクエリの最適化などがされにくいのでパフォーマンスは悪くなりがちです。前の会社でオラクルを使っていた頃はストアドは使わないので必死に頭を使い、一発で求める結果が得られるようにSQLを組み立てていました。今思うとあれはけっこう「SQL脳」を鍛えるのに役立っていたのではないかと思います。22:54SQLServerは、UPDATE~FROMが使えるので、好きでした。XXX=(SELECT~)・・・は、ちょっと。EXISTSよりは、わかりやすいと思います。DB2は、一番嫌いです。08:09伊藤淳一さん、おはようございます。例では最終出力のときのJOINでインデックスが使えないので最悪ですが、ワークテーブルを1つにするパターンならありかも知れません。ワークテーブルはメモリーに空きがあればそこを使うハズなので、それでロジックが分かりやすくなるなら良いと思います。WEBシステムではAPサーバがコネクションプールしてコネクションを使い回すので、重ならないように工夫が必要ですね。08:12ぴろしきさん、おはようございます。UPDATEの構文など「好き嫌い」の範囲ではないかと思います。明確な差が出るのは、やはりストアドプロシージャかな。ワンシステムの代表取締役。新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。書籍「プログラミング思考のレッスン」を読んでみた。利用規約ITmediaはアイティメディア株式会社の登録商標です。