SAPとMySQLが提携、次世代DBを共同開発 28
ストーリー by Oliver
merge_but_keep_interface()? 部門より
merge_but_keep_interface()? 部門より
GRA21曰く、"ERPで有名なSAPがMySQLと提携し、次世代RDBMSの開発に乗り出すそうです。SAPといえば、Adabasのソースを取得し、これをSAP-DBとしてオープンソースにしていたように記憶していますが、リリースを読むだけでは、事実上MySQLをベースにするということなのか、MySQLにSAP-DBの持つ強みをマージするのか、「共同開発」というのがどういう意味なのか、あるいはその逆なのか、など、はっきりとは読み取れませんでした。
SAPの最大の敵であるオラクルにとって、MySQLは鬱陶しい存在でしょうから、そういう意味でも面白い提携ですね。本当に両者の提携が形になって、MySQLベースのRDBが基幹に導入されるようになれば、オープンソースの基幹業務での利用も促進されるかもしれませんね。そういう意味では良いニュースではないでしょうか。参考:MySQL ABのリリース、SAPのリリース"
MySQL AB(RDBMSのMySQLの開発会社)がSAPからSAP DB関係の技術ライセンスを受け、SAP DBの開発をMySQLブランドで継続し、現行のMySQLと同様のGPLと商用ライセンスのデュアルライセンス方式で提供していく、ということみたいだ。その一方でSAPは稼働中のSAP DBシステムのサポートは続け、次世代MySQLの開発は両社が共同で行なっていく、と読みとれる。中長期的に両方のRDBMSがどのような形で融合もしくは存続するかは実際の発展をみてみるしかなさそうだ。
SAPのRDBMS (スコア:2, すばらしい洞察)
面倒なことから手を引きたいけど、自分たちのコードベースは存続させたいと考えたら、ブランド力のあるところに技術と一緒に売り払うのが手っ取り早いのかも。
つか、ぶっちゃけ、SAPDBってどうよ? 独自のブランドで存続するだけのプレゼンスは無いと思うんだけど。
Re:SAPのRDBMS (スコア:1, 興味深い)
SAP自体が「俺らはデータベースシステムそのものを売りたいんじゃなくて、業務用のフレームワークを売りたい」ことを体現した行動なのでしょう。
データベースシステム自体はほとんど仕様が確定してしまってここから大幅な発展を遂げる可能性は低いので、自社で開発してメンテナンスするよりはどこかの製品やオープンソースのものを借りたほうが割に合うと判断したのでしょう。
少なくとも日本国内ではかなり昔からSAP+Oracle/SQLserverのような事例が大半を占める(私が担当した範囲での話ですが)ので、判断が遅すぎたような気がしないでもないですが、自然の流れであることには違いないでしょう。
Re:SAPのRDBMS (スコア:0)
なら、なおのこと、どこのRDBMS業社とも手を組むべきではないのではないのでしょうか。わざわざ一社と提携しちゃったら、余計に売りづらくなると思うのですが。それより、どのRDBMSともうまく連繋できる、というこうずを作った方が、市場的には有利じゃないかと。
Re:SAPのRDBMS (スコア:2, 参考になる)
>Oracleって、SAPの敵なんですか?
Oracleの製品は,DBだけではありません.
SAPと競合する製品は, E-Business Suite (以前Oracle Applicationといっていたと思う) [oracle.co.jp]でしょうか.
Re:SAPのRDBMS (スコア:0)
まっとうに考えれば、極力自社ブランドで固める戦略を進めるなかで、より有利になるとふんだ選択なんだろうな。
Re:SAPのRDBMS (スコア:0)
MySQLにしても、PHP以外にSAPもフロントエンドとして使えますよというのは悪い話じゃない。
Re:SAPのRDBMS (スコア:1)
#SAPの製品は,R/3した知らないんですが...
Re:SAPのRDBMS (スコア:0)
Re:SAPのRDBMS (スコア:1)
検索するといくつかでてきますね.
古典的なDB設計の限界 (スコア:2, 参考になる)
現存するRDBMSはほとんどこの「設計が古い」という問題を抱えていながら、一方で新規開発は膨大な費用がかかり、しかも失敗する可能性(結構な数のRDBMS/ORDBMSが開発頓挫しています)を考えるとリスクが大きく、現状でだましだましやっていくしか道が残されてないので大変だなぁ、と思います。
オフトピ:設計の古さ (スコア:1)
どちらかというと、RDBMS は枯れた設計 & 枯れたコードベースのほうがいい(=嘘でも安心できる)と思ってるんですが、そうでもないのかなぁ... うーん、「古典的 DB 設計」の指すところを正しく理解してないかも。
具体的に、どういった点から「設計が古い」と言えるんでしょうか? 概念とは違うんですよね?
-- cooper
Re:オフトピ:設計の古さ (スコア:1)
その中では、SQLで叩けるISAMkから進化しているMySQLは余分な機能が少なく、将来性があると思います。
Re:オフトピ:設計の古さ (スコア:1)
# ああ、歯切れが悪い...
-- cooper
Re:オフトピ:設計の古さ (スコア:1)
市場の要求がずっと変化・高度化し続けている (スコア:0)
確かに枯れた設計&枯れたコードベースから感じる安
Re:市場の要求がずっと変化・高度化し続けている (スコア:1)
# 消費されなかったゴミを消し忘れて
# テーブルスペースを溢れさせたのは内緒です
-- cooper
Re:古典的なDB設計の限界 (スコア:0)
SAPの実装はとっても特殊でして、いわゆるテーブルつくってSQL文で検索、
という作り方ではありません。なんと、データをBLOBに押し込んで、独自の
APIでアクセスするという実装になってるそうです。しかもロック処理まで
自前でやっているという・・・すごくねぇ?
つまり、RDBMS使っていながら、RDBMSらしい使い方は全然してないみたい。
だからSAPはテーブル構造を公開していない。公開%帝6#P533;�
7ゎ�6いないというか、
公開したくてもできない。しかも動作スピードは遅い。
そのかわり、BLOBさえサポートしてい
古典的であるかは判らんけど独特ではある (スコア:0)
「SAPの実装」は SAP DB の実装という意味だと思ったけど、その話として「テーブルつくってSQL文で検索、という作り方ではありません。なんと、データをBLOBに押し込んで、独自のAPIでアクセスする」というのは違うんじゃないかと。
その解説は実装を説明してなくて、実装の結果のソフトウェアの使い方の説明ですよね。
「だからSAPはテーブル構造を公開していない。」っていっても、SAP DB って GPL/LGPLのフリーソフトだから調べれば原理的には判るはずだし(http://www.sapdb.org/7.4/sap_db_downloads.htm) そんな感じで文書のほ
Re:古典的であるかは判らんけど独特ではある (スコア:1)
>
>「SAPの実装」は SAP DB の実装という意味だと思ったけど、
ここでの「SAPの実装」は,「SAP R/3の実装」と読み替えると
判りやすいかと.
おしえて!エライ人 (スコア:1)
うっとうしい存在だったんですか?
ぜんぜんえらくないですが... (スコア:2, 参考になる)
The MySQL Benchmark Suite [mysql.com]によると、MySQL が SELECT と INSERT で一番良い成績を上げてますね。このテストでは、Oracle はかなり悪い結果がでてます。
んで、これ以外のベンチマークもやってみたらしいんですが、その結果 [mysql.com]について といった文面が添えられてます(*1)。
MySQL 陣営が言いたいのは、インストールした直後で一番使える RDBMS はどれ? って競争なのに、こっそりチューニングしちゃうのはズルイでしょ、ってことだと思うんですが、うーん、どっちも過敏に反応しすぎてるように見えます。まあ、こんなベンチマークを参考にする人も少ないと思いますけど。
# やっぱり「敵 vs 味方」な構図が必要なんですかねぇ...
# 個人的には幸せに開発できればどーでもいいんですけどねぇ...
MySQL と Oracle の両方を使い込んだことのある人なら、もっと的確にマシなことが書けるんじゃないかと思いますが、どなたかいませんかね?
(*1) 間違い勘違いは指摘のほどよろしくお願いします
-- cooper
Re:おしえて!エライ人 (スコア:1)
ところでは、Oracleとしては、SybaseもDB2もMS SQL Server
も全く脅威だとは感じていないそうです。じゃあ、OSSのPostgre SQL
はどうかというとこれも全く相手にしていないそうです。唯一脅威に
なりうるのがMySQLだと語っていました。実際NASAをはじめとして
OracleからMySQLに乗り換えているパワーユーザは多いみたいです。
Oracle = SQL Server = MySQL (スコア:1)
でしたが、Oracle Applicationが出たとたんに、M$のSQLServerと
仲良しになったかと思ったら、今度はMySQLですか。
確かにSAPは時代を読んでるかも知れません。
Re:Oracle = SQL Server = MySQL (スコア:1)
参考: MySQL, 大手ベンダーに宣戦布告 (スコア:0)
オフトピ (スコア:0)
#いや、思い出しちゃったもんで。
URL (スコア:0)
s/htpp/http/
どうなるのかな? (スコア:0)
・APO [sap.co.jp] の LiveChche
・BW [sap.co.jp] の Document Service
のようなものが挙げられます。
前者は安価にパフォーマンスを向上させる隠れた目玉機能だと思っています。
後者は KW [sap.co.jp] や SEM-BIC [sap.co.jp] と競合する面もありますが、TREX [sap.com](全文検索エンジン)は SAP DB 上で動かす必要があったのではないかなぁ?
これらも、今後は新しいRDBMSに移行しないといけないのかな?
# 悩めるコン猿なのでAC