MySQL は海外の安いホスティングサービスで高いシェアを持っているのですから、今後これらを使ってきた人たちがビジネスの世界で活躍するようになるにつれ、優位になっていくのではないでしょうか。知り合いの借りているサービスは二カ所とも使えましたよ。別料金だったり、データベース数に制限があったりするようですけど、専用の管理コンソールまで用意しているところまであるようでした。
そういえば Webmin からも操作できますね。
個人利用ですが、私の サーバ [manuke.com] も Powered by MySQL です。フリーの Sybase に一時入れ換えようとしましたけど、トランザクションを使いたくなるほど複雑なことは考えていませんし、MySQL はフリーウェアのためか、かゆいところに手の届く関数群があるので離れられません。
最初は無償データベースにてライセンス差額分の初期導入コストをカットしておいて、その差額を他のサービスに振り向けたり値引きに使い、段階的な非常に大規模になってきたなあと思ったら MySQL や PostgreSQL のチューンや Oracle、MS SQL Server への乗り換えを「ライセンスのコストやサポートに関するリスク、今後のメンテナンスのコスト」を含めて判断する、というご時世らしいですね。「景気が低迷する中でもユーザー企業はIT投資をやめるわけにはいかない。」ってことで、コストに敏感なユーザーが多数派になってきたのでしょう。
Web 版の記事には「フリー・データベース」を使ったパッケージ一覧が省略されていますが、MySQL (表中では1種類)よりは PostgreSQL (表中で 10 種類前後? うろ覚え)を使ったパッケージが多い印象がありました。
関連情報の質と量 (スコア:3, 参考になる)
もっと重要な問題に、関連情報の質や量といったものがあると思っています。
ちょっと大きな書店に行けばOracleやMS SQL Serverの本は何十種類とあるのに、
MySQLやPostgreSQLの本は片手で数えられるほどしか無い。
こういう状況では、いくら腕に自信があっても、「使いたくない」という人は
多いと思います。
例えば、商用サポートが何もしてくれないことは分かっていても、
自分で本を読んで調べてある程度のことは対処できる技術者は多いと思ってます。
RDBMSのソースを読むことは、基本的にSI屋さんの本業じゃないでしょう。
あとは若干でも知識のある(or 触れたことのある)技術者の数とか。
そういう部分を克服していかないと、ユーザー(技術者という意味で)は
あまり増えていかないように思います。
まぁ鶏と卵なのですが。
そして誰も知らない (スコア:3, 参考になる)
sapdb [sapdb.org]
これも、一応フリーなんだけどね…
PostgreSQLは? (スコア:2, おもしろおかしい)
だんだん対戦相手が弱くなっていくのはなぜ?
Re:PostgreSQLは? (スコア:1, 参考になる)
完全にフリーなDBと戦う意味がない(勝ち目がない)と考えたのではないでしょうか。
私はMySQLもPostgreSQLも使いますが、用途で使い分けしています。
でも速度が改善されたPostgreSQL7.xからは、MySQLを使う頻度って極端に減りましたけど、保守の簡単さでMySQLは捨てきれないものもあります。
Re:PostgreSQLは? (スコア:1)
あれはいわゆるカード型データベースというものであって、RDBMSとはまた用途も特徴も違うものだから。
# あれはあれで使いようではとても便利。
海外のホスティングサービスで高シェア (スコア:2, 参考になる)
そういえば Webmin からも操作できますね。
個人利用ですが、私の サーバ [manuke.com] も Powered by MySQL です。フリーの Sybase に一時入れ換えようとしましたけど、トランザクションを使いたくなるほど複雑なことは考えていませんし、MySQL はフリーウェアのためか、かゆいところに手の届く関数群があるので離れられません。
フットワーク (スコア:1)
フットワークが軽いというのと、何よりもフリーというのが
大きいのでしょうね。重いくせに高い導入費用がかかり、
しかも不安定なRDBが以下に多いかということでしょう。
何も分からないSEがサポート漬けになって利用するならともかく、
それなりのインターフェイスを実装する技術力があれば、
躓いてもメーリングリストなり何なりで十分フォローできますしね。
私はPostgreSQLしか使ったことありませんが(笑)
初期段階の投資費用を抑えるのに有効? (スコア:2, 参考になる)
最初は無償データベースにてライセンス差額分の初期導入コストをカットしておいて、その差額を他のサービスに振り向けたり値引きに使い、段階的な非常に大規模になってきたなあと思ったら MySQL や PostgreSQL のチューンや Oracle、MS SQL Server への乗り換えを「ライセンスのコストやサポートに関するリスク、今後のメンテナンスのコスト」を含めて判断する、というご時世らしいですね。「景気が低迷する中でもユーザー企業はIT投資をやめるわけにはいかない。」ってことで、コストに敏感なユーザーが多数派になってきたのでしょう。
Web 版の記事には「フリー・データベース」を使ったパッケージ一覧が省略されていますが、MySQL (表中では1種類)よりは PostgreSQL (表中で 10 種類前後? うろ覚え)を使ったパッケージが多い印象がありました。
重さや安定さは...こればかりは問題が発生したとき、どれだけ現場の技術者でカバーできるか、ですかね。これは無償データベースであっても有償のデータベースであっても同じだと思います。
Re:初期段階の投資費用を抑えるのに有効? (スコア:2, 興味深い)
営業が客先に謝りに同行してくれる。システムのことを
さっぱりわからん客に対しては、こういうのは意外と大きい。
--rena
Re:初期段階の投資費用を抑えるのに有効? (スコア:2, 興味深い)
悲しい人間の性ですね。
こういうのを聞くと、なにしに俺たちゃ「技術」をやってんだろ?と空しい気分に襲われたりします。
みなさんは、そうなりませんか?
そんなに菓子折りが好きなら、プログラマじゃなく菓子屋を呼べよ、と。
Hackerが「なるほど(=理解した)」と言ったときには、もう(本人にとっては(笑))謝罪は済んでいるのだそうだ。
では逆に上記の状況では、謝罪を言ったときには、理解はもう済んでいる、ということにされているのかも知れない。
しかし、謝罪は気分の問題である一方で、技術はそうではない。
となると、Hackerの姿勢は意味がある姿勢だが、後者はどうだろう?かなり怪しいものではないか?
Re:初期段階の投資費用を抑えるのに有効? (スコア:2, 参考になる)
相手が問題とその原因、対応について理解できて、むろん
こちら側の体制に問題がなければ、当然「菓子折り」など
不要なんですが。
ただいくらシステム的に矛盾がなくても、プロジェクトが
遅れるのは頭にくるわけで。カットオーバも迫ってるし :^)
ま、全てが論理的に片づけられないというのの典型ですかね。
--rena
Re:初期段階の投資費用を抑えるのに有効? (スコア:1)
>/dev/null
Re:初期段階の投資費用を抑えるのに有効? (スコア:1)
と言ってみたら、どうなるのだろうか?
Re:初期段階の投資費用を抑えるのに有効? (スコア:1)
Microsoft のおかげ? (スコア:1)
そして百家争鳴のデータベース市場で、ODBC の旗を振ったのは、、、どこの会社でしたっけ?
コンタミは発見の母
Re:Microsoft のおかげ? (スコア:2, 参考になる)
ソースの互換性が取れていればいい案件ばかりやってたせいもあるけれど、ODBCってあんまり使わないような気も。言語サイドが提供するミドルウェアに比べると、やはり1枚余計なレイヤがかぶるような気がして。
乗り換えの簡便性に貢献しているというと、やはりSQLじゃないでしょうか。
Re:Microsoft のおかげ? (スコア:1)
SQL 書ける人間なら COBOL 書ける人間並みに その辺に転がってますから色々と コキ使い^H^H^H^Hやりやすいです。
# でも弊社の若手は SQL を知らない。
# 未だ ISAM が幅をきかす職場だから... (T_T)
Re:Microsoft のおかげ? (スコア:2, 参考になる)
で、MS SQL Server 7.0 があっさりギブアップしてくれるので、困ってたりします。
DB 毎の「癖」を把握して、うまく対応しないと、複雑な SQL はきちんと動かないことも実感できますね。
たかだか、WHERE に IN を並べただけで、なんで落ちるんだぁ? > MS SQL Server 7
Re:Microsoft のおかげ? (スコア:1)
ドキュな開発やってるところでは、SQLといっても
(例えば)Oracle依存ばりばりなコードばっかり書いてるかも知れぬ罠。
まあそれはともかく、SQLも痛し痒しですね。言語仕様が汚いし。
あと、ODBCで楽をした記憶が無いのは、俺がWinでDBなクライアントといえば
Delphiでしかやったことがないせいでしょうかね?まあそうでしょうねBDE(ぉ。
Delphiはともかくとしても、JDBC(言語が限定されちまうけど)のシンプルさにビックリした後では
大抵(語弊?)のAPIを見ても心が動かなかったりする。あんな簡単に動いちまっていいの?って感じ。
Re:Microsoft のおかげ? (スコア:2, 参考になる)
ODBCドライバや関連ライブラリのバージョン違いに起因する動作の違いに泣かされた覚えがあります。
接続先DBMSはSQL*Server...やれNTのサービスパックだIEの新バージョンだと、ことあるごとにドライバのマイナーバージョンが変わって、そのたびに動作の違いを検証してMDACコンポーネント [microsoft.com]で強制的にバージョンを合わせて...苦労しました。
# MDAC2.1 位の頃です。最近は使ってないので分かりません
Re:フットワーク (スコア:1, すばらしい洞察)
> しかも不安定なRDBが以下に多いかということでしょう。
そんな悪いんじゃあみんなフリーを使いそうなもんだが。
でもね (スコア:2, 参考になる)
Oracleでも、Sybaseでも、なんでも使えばいいじゃない。
でも、ワシの仕事ではMySQLは当分使えん。色々と仕様が要件に合わ
ないんだよね。
Re:でもね (スコア:1)
>Oracleでも、Sybaseでも、なんでも使えばいいじゃない。
で、どれが適材か?という問題が厳然として残る、と。
もしかすると、技術的見地から比較して曖昧しか答えられないとき、
人はブランドを基準にして答え(らしきもの)を出そうとする、のかな。
余談:
あれ?最近のMySQLは、Transactionついたんでしたっけか?
Transactionの仕組みがDBについていると、お気楽プログラミングしたいときに、楽なんですよね。
#え?なんか使い方間違ってるって?(笑)
##更新矛盾とかエラーとかからの回復をするためのきちんとしたコードを自前で書くのは至極困難だ、という意味ですぅ。
Re:でもね (スコア:1)
大抵の顧客は技術的にはどうでもよくブランド(知名度)を要求するこ
とが多いという罠は確かに存在する。
Re:でもね (スコア:1)
MySQL-MAXでサポートされました。
Transactionは重いので、身軽が信条なMySQLはそのままです。
Re:でもね (スコア:1)
どの程度パフォーマンスが落ちるのか?という資料ってありますか?
いろいろ探してるんですけど、見つからないんですよね…。
Re:フットワーク (スコア:1, すばらしい洞察)
ある意味、ソフトウェアは、ブランド・ビジネス化しつつあります。
それが、ただ同然で手に入るLinux/GNUのCD-ROMが売れたり、OpenSSLで出せるにもかかわらずちゃんとしたCAから出た公開鍵証明書が使われたりする理由です。
昔のフリー・ソフトウェアは、ブランドがほぼ零に近かったかもしれないですが、今や、MySQL, Debian, Apacheなど、ブランド価値のあるフリー・ソフトウェアが、挙げればきりがないほど現われています。
iida
ブランドなるものの中身 (スコア:3, すばらしい洞察)
いったい何が達成できていれば買い手が「ブランド」と認識
してくれるのか、という点は掘り下げる価値があると思う。
技術屋さん自身は見逃しがちなことだが、企業にとって、君
と同じスキルを持った技術屋を雇い直すのは簡単なことでは
ない。君がいくらMySQLを使いこなせるといっても、君はいつ
か交通事故で死ぬかも知れないし、社長とけんかして辞める
かも知れない。そのときMySQLとやらに溜め込んだ会社の貴重
なデータを救い出せるという確信がなければ、理性のある企
業ならば決してMySQLを採用なんかしない。
OracleやDB2がエラいのは、そういう非常時に、金さえ払え
ば十分に有能な技術屋が来てくれるだろう、と企業が確信で
きるという点だ。誠に失礼な話だが、MySQLのサポートを提供
する会社があるとしても、いつまで続くか分からないような
会社しかないとしたら、MySQLにブランド力があるとは言えない。
Re:ブランドなるものの中身 (スコア:2, 興味深い)
MySQLの欠点と言われている事は、トランザクション、トリガ、ストアードプロセジャ、ビュー等の便利な機能が無い事ですね。トランザクションはどなたかも書かれておられるように、MAXでは利用可能です。ストアードプロセジャ、ビューもDBMSとすれば魅力的で便利な機能ですが、システム構築/運用的には脆弱点となりかねないのはご存じの通り。トランザクション、トリガについて言えば、それは何のペナルティも無しに利用できる機能では無い事を考えるべきでしょうね。また、トランザクションの目的と言われている一貫性のあるデータ更新も、場合によっては万全では無い事もまた基礎知識ですね。
実際に業務を分析したことがある方なら自明の事ですが、DB処理に占めるトランザクションの必要性には限りがありますね。そしてDBMSの実装に携わった事があれば、トランザクション処理というものがどれだけ重いのかは、これまた自明の事です。トランザクションが無いDBMSで一貫性のあるデータ変更を行う、これはある程度の基礎知識を持っているエンジニアには児戯に等しい事ですし、実装だってそう面倒な事ではありません。ですが、そういう基礎知識を持って居ないエンジニアには、至難となる事もあるでしょうね。
Oracle8.0.3/4/5に関して更に言えば、死ぬ程苦労した経験がありますね。行がなんかの加減で二重に出たり出なかったり、プライマリキーのフィールド名次第では結果がまったく返って来なかったり、阿呆なクライアントライブラリ+ProCのワケワカで簡単に数百MBのメモリを使うクライアントアプリケーションを量産出来たり、VBSとの相性も最悪だし、MySQLのクライアントライブラリなら非常に簡単な行をタグドデータに落とす事がOCIでは異様にステップを食って激烈に面倒だし、等々々々々。
天地の地の方のOracle使い(資格を持っているとしても)の典型としては、Oracle以外に選択肢が無い、があるでしょう。比較するものを全く知らないなら、当然比較することなぞ出来ません。ペーパーだけの比較でも意味が無いでしょう。相当使い込んでみて、始めて比較する事が可能になると思いますよ。単にメリットだけに注目するのでなく、総合的な評価を行うなら、便利だが重くて全体的に遅いDBMSと、軽くて全体的に速いが限られた処理を行う事に労力を使うDBMSとの取捨選択は、かなり悩ましい事になるはずです。
「それとも何か。人的コストは度外視ですか?」、単にコストのみを考えるプロジェクトマネジメントって簡単に破綻しません?
考えなければならないのはC/Pです。その辺の道端に転がってるにーちゃん、ねーちゃんを幾ら安い給料で大量に拾って来ても、何の役にも立たないと思いますよ。単なる馬力勝負の仕事なら給料が2倍の人が2人分の仕事が出来るというのは多分に誤りですが、スキル的となれば給料が半分の人が何千人束になっても1人に敵わない事はあるでしょう。失敗するプロジェクトマネジメントとは、頭数を加算的に勘定している、というのはあると思いますよ。トランザクションやトリガが無いDBMSで、それと同等の事を実現出来る程度の技術や知識を持った人が1人もいない、その様なプロジェクトは極めて打たれ弱いのでは、と思いますが。
Re:フットワーク (スコア:2, 興味深い)
ちゃんとしたCAから出た公開鍵証明書じゃないと、公的な場面ではあまり意味がないと思うけど。自分自身で署名した公開鍵証明書がオンラインショップで使われていたら、規模によっては胡散臭いし。ソフトウェアのブランドと言うより、そのCAに対するブランド意識だと思う。
とは言え、一番大きな理由はIEで初心者には意味不明なダイアログが出るかどうかの有無だと思うが。(w
Re:フットワーク (スコア:2, 興味深い)
きちんと性能、リスク、コストを勘案して、選択肢を最大限に広げるようになってきたのでしょうね。
あと、フリーソフトウェアであれば、試用コストも最小限で済むというのもあるかもしれません。
Re:フットワーク (スコア:1)
と言うより、普通ソフトウェアの使用許諾書で、「何があっても一切責任をとらない」
という旨が書いてあるはずです。
つまり、結局はiidaさんの言うようにブランドなんですよ。
Re:フットワーク (スコア:1)
あと、フェイズアウトが早すぎるという意見も。
みんなそれなりに、貧乏な時代なのだな。
Re:フットワーク (スコア:2, すばらしい洞察)
オープンソースには難しいっすよ。多分。
結局、ブランドというのは「(自分がorみんなが)知っているものは信用できる」
という心に立脚します。しかも、このように考えるのは情報が少ないか、
情報の取捨選択をする能力がない場合です。
このような状況の人に周知するには、雑誌やTVでがんがんと広告を打つ必要が
あります。しかし、これは資金力だけがものを言う分野です。
#まぁ、オープンソース一般に関しては、IBMあたりが頑張ってくれる
#かもしれませんけど。DBは利害が対立してるからなぁ。
#自前ではDBを持たないSunに期待、ということにしときます。
Re:フットワーク (スコア:1, 参考になる)
まぁ、明らかに個人ユースではありませんね。
Re:フットワーク (スコア:1)
# 個人的には何でもかんでも Oracle に
# 載せて ODBC 経由でつつきに行く的な
# 設計の流行には (X_X) なので、
# どちらかと言えば RDB を使うべきものと
# そうでないものとの適材適所を
# N経ソフトウェアみたいな「影響力のある」
# メディアが警鐘ならしてくれんかな~と
# 思ったり。
# ソースのバージョン管理なんか
# 生ファイルでやれや>某社製品
Re:フットワーク (スコア:1)
たしかオラクルは推奨してなかったと記憶しています。
(古いOracle8のマニュアルに「できればUNIX版を使え」って記述があったような…)
# テストプログラムを走らせる実験台には手頃でいいですね。NT版は。
notice : I ignore an anonymous contribution.
関係ないレス(レベルの低さについて) (スコア:1, 荒らし)
もうね、アフォかと。ヴァカかと。
お前らな、そんぐらいぐぐって調べろっつーんだよ、ヴォケが。
挙句の果てには#の後に書いちゃってるヤシまでいるし。
もう見てらんない。
某掲示板からスラド民がバカ扱い受けるのは当然だとオモタ。
ここは厨房の馴れ合い場か?こんなレベル低くていいのだろうか?
せめて最低限のことぐらいしてから来い。目障り。
Re:関係ないレス(レベルの低さについて) (スコア:1, おもしろおかしい)
これから土民って呼ばれそうな予感…
Re:フットワーク (スコア:1)
> 私にはMySQLとかPostgreSQLはツライっす。
??? どういう意味?
いや、おいらはOracle知らないので。
Re:フットワーク (スコア:1)
http://www.postgresql.jp/document/pg653doc/ej/user/sql-beginwork.htm
http://www.vce-lab.net/mysql-storage/faq.html#server
Re:フットワーク (スコア:1)
いや、おいらもそう思ったんですけど、OracleとかSQL Serverとかは知らないので、
OracleやMS SQLには、おいらの知らないトランザクションの機能があるのかなぁと思って。
Re:比較的小規模な (スコア:2, 参考になる)
実際、トランザクションなしのDBMSは幾つかありますが、
整合性をとる同等の仕掛けはちゃんと存在するので問題になりません。
(プログラムを移植するときはめんどくさいですけど)
似たような話に、行ロックの話があります。
「オラクルには行ロック機構があって高速に動作するのに他のDBMSはページロックやテーブルロックどまり」というやつです。
実際には「オラクルは行ロックがないと使えない設計だが、他のDBMSは行ロック無しでも使える設計になっている」だけみたいです。
排他をかける際の考え方の違いなんですけど...。
# 現在、この件で嵌ってます。
# オラクルにテーブルロックかける馬鹿者がいるんです。(insert文が排他ロックエラーで異常終了しちゃいます)
# たぶん、どっかのVBのサンプルをそのままコピペしたんだろうが...
# 使用するDBの特徴くらい、ちゃんと勉強してくれ...迷惑だから。
notice : I ignore an anonymous contribution.
Re:比較的小規模な (スコア:2, 興味深い)
トランザクションを使用できます。
トランザクションが必要ない、検索のみのテーブルには高速な MyISAM を使うこともできますし。
# ひとつのDB内で、テーブルごとに MyISAM, InnoDB, BDB を設定できます。
http://www.mysql.com/documentation/mysql/bychapter/manual_Table_types.html
昔の (スコア:1)
つまりSQLインターフェイス付きのISAMと思えばイイわけぢゃな(^^
かつてオフコンってのを使っていた用途には充分ですな。
#その昔ワシはTOSBAC DP/10てのを使ってたが、コレは開発マシン
#としても、とても使いやすかった。今の若い衆がPerlなんぞでWEB
#アプリケーション作っているのを見るとエライ気の毒に見える。
Re:昔の (スコア:1)
(スコア+1, 興味深い)したいです。
WEBアプリケーションを作る開発環境として
Perl等で組むよりどう優れているのでしょう?
SmallTalk/Squarkのように、
言語・環境が一体化しているのでしょうか?
Re:昔の (スコア:1)
(最近アプリケーションサーバーってのをを見ていると、ちょっとプログラム替えるだけで再起動。なんだか凄く面倒くさそう)
Re:カスとか書くなよ (スコア:2, おもしろおかしい)
# ごめんなさいごめんなさいごめんなさい _(_ _)_
Re:それにしても (スコア:1)
# 半分以上マジ。
Re:それにしても (スコア:1)