アカウント名:
パスワード:
そんな悪いんじゃあみんなフリーを使いそうなもんだが。
ある意味、ソフトウェアは、ブランド・ビジネス化しつつあります。 それが、ただ同然で手に入るLinux/GNUのCD-ROMが売れたり、OpenSSLで出せるにもかかわらずちゃんとしたCAから出た公開鍵証明書が使われたりする理由です
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
フットワーク (スコア:1)
フットワークが軽いというのと、何よりもフリーというのが
大きいのでしょうね。重いくせに高い導入費用がかかり、
しかも不安定なRDBが以下に多いかということでしょう。
何も分からないSEがサポート漬けになって利
Re:フットワーク (スコア:1, すばらしい洞察)
> しかも不安定なRDBが以下に多いかということでしょう。
そんな悪いんじゃあみんなフリーを使いそうなもんだが。
Re:フットワーク (スコア:1, すばらしい洞察)
ある意味、ソフトウェアは、ブランド・ビジネス化しつつあります。
それが、ただ同然で手に入るLinux/GNUのCD-ROMが売れたり、OpenSSLで出せるにもかかわらずちゃんとしたCAから出た公開鍵証明書が使われたりする理由です
iida
ブランドなるものの中身 (スコア:3, すばらしい洞察)
いったい何が達成できていれば買い手が「ブランド」と認識
してくれるのか、という点は掘り下げる価値があると思う。
技術屋さん自身は見逃しがちなことだが、企業にとって、君
と同じスキルを持った技術屋を雇い直すのは簡単なことでは
ない。君がいくらMySQLを使いこなせるといっても、君はいつ
か交通事故で死ぬかも知れないし、社長とけんかして辞める
かも知れない。そのときMySQLとやらに溜め込んだ会社の貴重
なデータを救い出せるという確
Re:ブランドなるものの中身 (スコア:1)
>という確信がなければ、理性のある企業ならば決してMySQLを採用な
>んかしない。
Oracle使いがMySQLからデータを引き出して移し替えるのが出来ないとは思えないですね。まあOracle使いと言っても、レベルには天と地の開きがあるのですから、地の方しか雇えないなら、それは出来ない場合もあるでしょうが。
MySQLで出来る事はOracleでも出来る、その逆は難しい場合がある、は正しいでしょう。それを使うエンジニアとなると、話が逆転する場合が結構あったりしますね。MySQ
Re:ブランドなるものの中身 (スコア:1)
> が必要な場合「どうやれば実現出来るのか、同様の成果を得る事が出来る
> のか」を考えなければならず、比して突っ込 んだ、あるいはプリミティブな
> 知識や経験が必要になるでしょう。
他のところでも同じようなことを書きましたけど、それが本当に望ましいのですか?
「お気楽なSQLを書いてもそれなりのパフォーマンスが出ること」って、
非常に重要だと思うんですけど。
コストを「労力」として投入するか、「金銭」として投入するかの違いだけでしょ?
結局コストがかかってることには違いないじゃん。
カーネルとかでも言えることだけど、プリミティブな部分(究極的にはソースコード)が
開かれてるかどうかなんて、結局は使う側からしたら関係なくて、
いかにしてコストパフォーマンスの優れたシステムを組むか、じゃないの?
SI屋さんの仕事は。
それって、結局MSあたりが言ってる「Linuxは隠れたコストがかかる」っていうのに対して
何ら反論できてない気がするんですが。
「やればできる」のはいいけども、「やらなきゃならない」ならばコストが増えるだけ。
それとも何か。人的コストは度外視ですか?
「お気楽に使える」ことに対する評価が、オープンソースな人たちは不当に低いと思う。
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:ブランドなるものの中身 (スコア:1)
Oracleとかの商用DB使う場面って、運用実績に見られる安定性求める場面が多いと思いますし、現場で高耐久テストをした事の無い他のDBなんか使うのは難しいと思います。(そのためにわざわざ他のDBでテストするのなんかはコストから考えて論外でしょう)
使える・使えないとかの問題じゃ無くて、やっぱり実績は重要だと思います。運用時にトラブル起こす可能性がある事を考えると、ライセンス料なんかケチってもしょうがないでしょう。
要はどこまでの安定性を求めるかでDBの選択が変わるのであって、安いからといって安易に移れるものでは無いという事です。
Re:ブランドなるものの中身 (スコア:1)
その場合に顧客にプリミティブな知識を要求するのは難しいと思います。
あと、プリミティブな知識が必要になっちゃうと引き継ぎが大変かも。
きちんとそういうところまでドキュメントにしておけ、とは言われるでしょうが。
ただ、問題なのはOracleが
>「お気楽なSQLを書いてもそれなりのパフォーマンスが出ること」
と言うわけでも無いと言うことですねえ。
>「お気楽に使える」ことに対する評価が、オープンソースな人たちは不当に低いと思う。
オープンソースな人、なんでしょうかねえ。
(少なくとも日本での)商売での実情を知らない人なんじゃないのかな。
それとも凄く優秀な人で知識の習得コストがほとんどゼロだとか。
Re:ブランドなるものの中身 (スコア:1)
つまり、
「OracleにあってMySQLには無い機能でも、
MySQLではやり方によっては実現できて、
しかもMySQLで実現できるエンジニアの方がレベル高いよね」
みたいな話になってたので、それってそんなに重要?いいことなわけ?と
思っただけで。
もちろん、安定性や実績が明らかになっていることが大事、
そういう場面で、Oracleなどの商用RDBMSが使われる、というのは
そりゃそうだろうと思います。
今のところは。
Re:ブランドなるものの中身 (スコア:1)
>「OracleにあってMySQLには無い機能でも、
>MySQLではやり方によっては実現できて、
>しかもMySQLで実現できるエンジニアの方がレベル高いよね」
>みたいな話になってたので、それってそんなに重要?いいことなわけ?と
>思っただけで。
それについては同感です。ヘボなOracle使いも多数居ると思いますけど、殆どはもっとクリティカルな環境向けの高度な設定とか運営とか出来る人がメインだと思いますし、かなり広範囲な勉強しないと運営出来ないって点ではよっぽどOracle使いの方が高度な事してると思います。
...こういう論点で比べる事自体意味無いと思いますけどね。