Oracle派なのに、なぜMicorsoftなのか - SQLer 生島勘富のブログ

　Micorsoftさんのセミナーでお話しさせて頂くことになりました。首都圏の方、お時間があればご参加ください。

　https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032457242&culture=ja-JP

　今回は入門編なので、過激なことを言ったりしないので、そっち方面の期待はしないでくださいね。

技術者が盲目的に信じる迷信

　正直にお話しすると私はOracle派です。

　SQLを書くときも頭の中では、まず、Oracleの方言が出てきて、それをSQLServerなり、PostgreSQLなりに翻訳しています。最初に触ったものの印象が強くなるということでしょう。

　私が業界に入ったとき、最初のプロジェクトがOracle7で、次がSQLServer6.5でした。

　SQLServer6.5は周りのツールはOracleより良くできていました。というよりOracleのツールはバグだらけの上、本当に重くて、全く使えなかったのですが、ツールは自作すれば済む話だったので気にならなかった。本体のDBの能力でSQLServer6.5では痛い目に合い、Oracle派になりました。

　「DBはOracle」とか、「SQLServerは……」というのはベテランに多く、それは、SQLServer6.5の頃の印象が深く残っているためではないかと思います。事実、私がそうです。また、ベテランは社内でそれなりのポジションにいる割合が高いので、余計に「DBはOracle」などという迷信が広まっているのではないかと思います。

　今となっては迷信なのです。（まあ、私も迷信の布教をやっていた訳ですから間違いない）

　ストアドプロシージャが流行らない理由は、OracleのSELECT系のストアドプロシージャがあまりにも書きにくいために、SELECT文はストアドプロシージャ（ファンクション）にできないという迷信が広がってしまったことにあります。そのため、ストアドプロシージャは「バッチ処理のためにある」と考えているという人が相当数いますが、それもOracleが作った迷信です。

　その迷信がなければ、生のSQLを書いたり、O/Rマッパなどを使うよりも、ストアドプロシージャを使う方が圧倒的に工数が下がるということは分かるのですが……。当たり前の話で、データベースの構造はRDBMSの管理下にあるのに、DBに対するインターフェース（SQL）がRDBMSの管理下にないということはデメリットしかないのです。

　あまりに強固な迷信があるために、その当たり前すら通用しません。

SQLServerは生産性がとにかく高い

　時は流れ、現在、DBとしての性能は各社大差がなくなりました。個人的には、数十GByteぐらいまでのシステムなら、PostgreSQLで十分じゃないかと考えています。

　まぁ、保守するときのツールには差があるかもしれませんし、それぞれが持つ特殊な機能が必要なシステムであるならば、好きなベンダーのRDBMSを使えばよいでしょう。しかし、ストアドプロシージャで書くときの生産性は、明らかに数倍（＝数百％）という差がつきます。

　確かに、Oracleでは、SELECT文のストアドプロシージャ（ファンクション）は書きにくいために、ストアドプロシージャを全面的に使う開発というのは非常に少ないです。そんなOracleでも、ストアドプロシージャを利用することで工数は下がります。

　システムで使われるSQLのうち8〜9割はSELECT文になります。SQLServerは、メインになるそのSELECT文のストアドプロシージャの記述量が2〜3倍前後少なくなり、工数に換算すると更に大きな差が付くのです。

　DBに係わるビジネスロジックの量と、UIに係わるビジネスロジックの量は、プロジェクトによってまちまちですから一概に言えませんが、ストアドプロシージャを利用するならばOracleなどを使うメリットは全くない。Oracleなどから乗り換えても開発費が500万〜1千万円規模以上のプロジェクトなら乗り換えコストはペイするでしょう。PostgreSQLであったとしてもライセンス費も楽にペイするでしょう。

　SQLServerなら、それぐらい生産性が上がります。