【必】未だにPostgresを馬鹿にするOracle厨【死】
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
03/09/16 10:07ID:oMO5pfC/"PostgreSQLは中小企業のどうでもいいDBにしか使えない"
とか言うんなら、PostgreSQLは信頼性に欠けるという証拠出してみろや。
GoldやらPremiumやらで努力してきたのはわかるが、もうお前らの時代は終わった。
じゃあね!
0153NAME IS NULL
03/10/19 23:35ID:???> しってるかな?
「ユーザー」の目的は「使うこと」であって「（RDB自体を）開発すること」ではない。
「ソースを読まずに」使えれば、それに越したことはない。
レベルが高かろうが低かろうがそれは一緒。
「ソースを読む」というのは「ユーザー」にとってはあくまで最終手段でしかない。
時間がかかるし、コストがかかる。
ソースがあるから本なんて無くていい、と言い放つのはDQN。
そもそも、なぜ「ユーザー」がソースに目を通さなければならないのか？
その状況はベストなのか？ 考えたことがないのか。
よっぽど単価安い仕事してんだな。
0154NAME IS NULL
03/10/19 23:43ID:???Oracle使ったシステム組むのに、本を買わずに
ソースだけ読んで何とかしようとする香具師いるか？
普通、それなりに情報がまとまってる本を買うだろ。
ユーザーのレベルに合わせた本を。
そーゆー話だ。
0155NAME IS NULL
03/10/19 23:50ID:???>>出版事情と開発レベルの相関をきっちり説明しろよ。
おまえ、こっちの質問になに一つ答えてないやん。
0156NAME IS NULL
03/10/19 23:58ID:???> レベルの高いユーザーが増えれば、それだけ性能や機能に対する要求が高まって、
> MLでの議論も増える。
> 当然、よく議論になる機能の方が（ニーズが高いと判断されて）実装されやすい。
> 性能改善に関してもそう。
> BSDにせよLinuxにせよ、複雑なソフトウェアコンポーネントに関しては、
> きちっとした資料が揃ってるもんだ。
> だからこそ先人の成果を踏台にして、その先に進めるんだ。
説明はしてるんだよね。
レベルの高い資料が少ないということは、レベルアップする人が少ないということ。
レベルの高い人が少ないということは、コミュニティでのレベルの高い議論の機会が減るということ。
レベルの高い議論の機会が減るということは、実装（or改善）される機会が少なくなるということ。
0157NAME IS NULL
03/10/19 23:59ID:???あとな、
>>出版事情と開発レベルの相関をきっちり説明しろよ。
それを言うなら「因果関係」な。相関関係と因果関係の違い、分かるよな？
0158NAME IS NULL
03/10/20 00:03ID:???本のレベル低->ユーザレベル上がらん
これはアグリーね。
でも、
ユーザレベル低 ->開発レベル低
ってのは一般論すぎて、PostgreSQLにはあてはまらんだろうと。
かつ、
本のレベル低->ユーザレベル低 ->開発レベル低
==>本のレベル低->開発レベル低
ってのは分かんないから説明しろよと言ってるわけ。
お前は、一般論に逃げたり、
開発にコミットできるレベルのユーザ(高レベルユーザ)とか、
低レベルユーザとか定義して
都合のいいように使い分けて話を逸し続けているが、
最初の質問である、
本のレベル低->ユーザレベル低 ->開発レベル低
==>本のレベル低->開発レベル低
このお前の最初の論理ステップを、
一般論を使わず、
PostgreSQLに関して具体的な事実だけを使って説明してみせろと。
思うにだな、
本のレベル低->ユーザレベル低
程度なら俺もこんなにしつこくしなかったんだが、
ユーザレベル低 ->開発レベル低
これのステップが理解できんのだ。
一般論としてはそういう(ユーザレベル低 ->フォードバック少->開発レベル低)
こともあるかもしれんが、
PostgreSQLに関してはどうなのよ。
具体的な説明が欲しいわけよ。
因みにだな、プロならオンラインドキュメントを読もうぜ。
そこにはチューニングやオプションについてきちんと説明してあるから。
(たしかに、説明不足の部分はある。それは認めるがそれってパラメータ数個程度だろ)
0159NAME IS NULL
03/10/20 00:10ID:???おまいら これでもみて議論の仕方学んどけ
http://homepage1.nifty.com/fujiwo/develop/oo/dscsnptn.html
0160NAME IS NULL
03/10/20 00:15ID:???共有バッファプール一個しかないのはどうなの？ 問題ないの？
パーティショニングどうやんの？
nested transaction/savepointできる？
統計情報って今あるので本当に十分？
与えられたCPUやメモリを本当に効率的に使い切ってる？
PITRできる？
バックアップ/レストアって、あんな方法で本当に効率いいの？
テラサイズになっても時間的に大丈夫？
Opteronの性能を最大限引き出すにはどうすればいい？
商用DBMSなら当然押さえてるこのあたりの機能や性能、
PostgreSQLユーザーで気にしてる人、どれだけいる？
0161NAME IS NULL
03/10/20 00:16ID:???つか長すぎ。
0162NAME IS NULL
03/10/20 00:28ID:???I/Oの分散なんてできるかボケ、tablespaceなんてあるかボケ、
共有バッファは一つでいいんじゃボケ、
パーティショニングなんてないんじゃボケ、
トランザクションをネストするなんて馬鹿のすることじゃ、
得られる情報を駆使して稼働させるんじゃボケ、
CPUメモリなんぞ不足したら追加じゃ、なんのためのフリーソフトじゃ、
CPU毎のライセンスなんてケチなシステムじゃねえぞー、
PITRなんぞ関係ない、
バックアップはホットバックアップだエッヘン、インクリメンタルじゃないけど、
16Tまでなら使えるぜ、遅けりゃ早いCPUとディスクを使えってんだ。
以上。
0163NAME IS NULL
03/10/20 00:33ID:???（´・ω・｀）
0164NAME IS NULL
03/10/20 00:37ID:???もちろん、PostgreSQLを選択する場合、
そういう点をクリアにして、
それでもPostgreSQLでOKという場合にのみ使うんだよ。
だから、システム毎にDBの選定時点では気にするが、
開発、運用上で気にすることはない。
だってほとんどの項目はまだPostgreSQLでは未実装だったり、
機能が開発途上だったりするから。
で、どうなの？多機能システム使ってる人は偉いの？
F1マシンに乗ってる素人と、自家用車に乗ってるレーサーでは
運転が簡単なぶん自家用車のレーサーの方が劣るの？
0165NAME IS NULL
03/10/20 00:43ID:???つまり、レベルの低いものをレベルの低いなりに使う、という結論でよろしいか？
0166NAME IS NULL
03/10/20 00:50ID:???そこそこでよければPostgreSQLかMySQL。世の中そういう流れ。
Oracleは下降線。
F1マシンと自家用車の比較は不可能。F1は速いけど、自家用車は荷物が積める。
レベルがどうこういうのは135か。
簡単なWEBシステムやミッドレンジのDBがOracleからPostgreSQLに流れているのは
比較した結果PostgreSQLの方が＊その目的に＊適しているからだろうねえ。
0167NAME IS NULL
03/10/20 00:53ID:???また話をずらしたね。
今は使ってる人の話じゃないよ。開発してる人のレベルの話じゃないの？
ジャンボジェットを開発する技術力とセスナを開発する技術力。
どう考えても、ジャンボジェットの方がレベルは上。
0168NAME IS NULL
03/10/20 00:58ID:???議論パターン「話題そらし」を読め！
http://homepage1.nifty.com/fujiwo/develop/oo/dscsnptn.html#change
0169NAME IS NULL
03/10/20 01:00ID:???> 比較した結果PostgreSQLの方が＊その目的に＊適しているからだろうねえ。
純粋な技術的比較だけじゃないよね。その選択の理由は。
技術的な比較でPostgreSQLが優れてるのなら、
ハイエンドで他の商用RDBMSを選ぶ理由がないもん。
要するに、商用RDBMSと比較して、機能も少なくて性能も劣るけど、
ローエンドではそれほど問題にならないし、それにタダだから、って話だべ？
その利点は否定してないよ。
だけど、商用RDBMSと比較して、使われ方や使ってるユーザーの
レベルが全体的に低いということは否定できないと思うよ。
だって、そういう機能しかないし、そういう使われ方しかしてないもん。
0170NAME IS NULL
03/10/20 01:01ID:???おまえ、 はやく質問に答えろよ。逃げんなよ、ボケ。
>>また話をずらしたね。
これに答えた結果なんだがな:
>>>商用DBMSなら当然押さえてるこのあたりの機能や性能、
>>>PostgreSQLユーザーで気にしてる人、どれだけいる？
お前、読解力ないだろ。
>>ジャンボジェットを開発する技術力とセスナを開発する技術力。
>>どう考えても、ジャンボジェットの方がレベルは上。
ジャンボの開発者はユーザからのフィードバックがくるから、
技術力が高いんだろ。
わかった、わかった。おやすみ、Oracle野郎。
0171NAME IS NULL
03/10/20 01:10ID:???すごいメカニズムでも適していなければダメなの。
適してるってのはコストもメカニズムもなにもかも含めて考えるわけ。
で、オールマイティなメカニズムなんてないの、普通は。
で、目的に適したものを選ぶの。
別にハイエンドで使えるもの＝凄いじゃあないことくらい
わかってんだろうな。
0172NAME IS NULL
03/10/20 01:10ID:???>>>PostgreSQLユーザーで気にしてる人、どれだけいる？
これの答えが、
> で、どうなの？多機能システム使ってる人は偉いの？
これでつか？
別に機能の話してるだけじゃないんですけど。
「機能や性能」と書いてあるでしょ。
RDBMSとしての基本的な性能や機能において
PostgreSQLが（商用RDBMSに比べて）劣ってないという立証は？
ハイエンドで商用RDBMSが選ばれる理由をどう考えるわけ？
そういうの開発できる方がレベル高いと思わない？
思わないならまぁいいけどさ。
0173NAME IS NULL
03/10/20 01:12ID:???「適している」と「レベルが高い」が違うことくらいは理解してます。
レベルが高いからといって適しているわけではないのはその通りです。
逆に、適しているからといってレベルが高いというわけでもありません。
0174NAME IS NULL
03/10/20 01:13ID:???>>そういうの開発できる方がレベル高いと思わない？
釣りでつか。
0175NAME IS NULL
03/10/20 01:15ID:???『俺はOracle使ってんだ、レベル高いんだ。』
ってことね。
シルバー？
0176NAME IS NULL
03/10/20 01:18ID:???まぁいいや。
オモチャの機能や性能で満足している香具師はそのまま遊んでてください。
おやすみ。
0177NAME IS NULL
03/10/20 01:22ID:???>>276
じゃあ、お前が本書けや、ボケ！！
ちゃん、ちゃん。
(自作自演じゃないよ。)
0178NAME IS NULL
03/10/20 20:21ID:???IBMに注文すれば、隠してる部分以外全部情報は出る。
それが商用DBの良いところ。
ただ、IBMのマニュアル作りが、ウンコ、糞、白痴、って言う
議論はしてみたいけど、すれ違いなので（終
0179NAME IS NULL
03/10/20 20:22ID:???そうか？フリーソフトなんだから、出版事情はとても大切なポイントだと思うぞ。
商用DBだとマニュアルが有るんだから。
0180
03/10/20 20:49ID:cUZE6nZ9> ただ、IBMのマニュアル作りが、ウンコ、糞、白痴、って言う
> 議論はしてみたいけど、すれ違いなので（終
機械翻訳の日本語マニュアルを読むよりは、
英語のマニュアルに当たったほうが正確だよね。
0181NAME IS NULL
03/10/20 22:00ID:???日本の出版事情とポストグレスの完成度になにか関係があるかのような
連想をしていた奴がいただけ。
0182NAME IS NULL
03/10/22 23:04ID:z9g2utCMふーん、で、君のコントリビューションはどれかな？
# 見るだけ、いじるだけなら、サルでも出来るだろうに（藁）
0183NAME IS NULL
03/10/22 23:08ID:z9g2utCM藁
ジャンボは、軍のコンペに落ちた機体だ、ってのは、当然知ってるよね？
旅客用やカーゴで使われているB-747は、つまりは軍に採用されなかった機体の廃物利用。それがたまたま当たっただけさ。
ふーん、で、君のコントリビューションはどれかな？
# 見るだけ、いじるだけなら、サルでも出来るだろうに（藁）
0184NAME IS NULL
03/10/22 23:09ID:z9g2utCMおっと、前のカキコが残っちまった。
0185NAME IS NULL
03/10/23 10:34ID:q9+Wqi7h異常にきれて反論しているやつがいるけど、本が原因の一つであることも否定できないだろ?
まあどうせきれてるのはSBPか技評の香具師なんだろうけどさ。
そもそもPostgresのインストールすら自力で出来無い奴はDB扱うなよな。
明らかに出版社は空気読めてないよ。
0186NAME IS NULL
03/10/23 14:29ID:???postgresql本 25冊
内訳
技術表論社 6冊 (うちシーラカンス本３版で３冊、ishxi氏著作計４冊)
日経BP社 2冊
秀和システム 2冊
セレンディップ 2冊
インプレス 2冊
翔泳社 2冊
ローカス 2冊
オーム社 2冊
ソーテック 1冊
ピアソン 1冊
ソフトバンク １冊
オライリー 1冊
テクノプレス 1冊
185の予想に反して、ソフトバンクは１冊しかpostgresql本がない。
ishxi氏が４冊(日経BPも含めると5冊)書いていることを除けば
各社1-2冊程度。これって普通？
とにもかくにもシーラカンス本が日本のpostgresql本の基準
になってしまったことが....なのかね。
>>明らかに出版社は空気読めてないよ。
これはお門違いかな。出版社は売れてなんぼ、
オンラインドキュメント読み漁るひとははなっから相手にしていない。
インストールも出来ない人が大事なお客様なんだから。
それを言い出すと、日本人が英語が話せないのは出版物のレベルが低いからとか
なんとでも言えるよ。
ところでmysqlはどうなんでしょ？
やはりamazonで調べると洋書ではpostgresqlが18冊に対してmysqlは109冊で圧倒。
でもmysqlの和書は17冊。
mysqlってまだ副問い合わせすらサポートしていないんだよね。
0187
03/10/23 14:51ID:lK+ceeqE0188
03/10/23 14:55ID:lK+ceeqEありゃ、これって副問い合わせって言うのか…
0189あぼーん
NGNG0190NAME IS NULL
03/10/23 21:49ID:C9Vx+vuDSQLite と Oracle ありゃいい。開発用や中小は SQLite、大企業向けはOracle
0191NAME IS NULL
03/10/23 22:00ID:???SQLiteでOKな開発ってなによ？かなり限定されるじゃん。
本当に開発経験あんの (W
#実はSQLiteでシステム組んだことある。
#だがそれはSQLiteしかインストールできないすごく小さなシステム上での話。
#だからSQLiteの限界と中小でのニーズにかなりの乖離がある
#ことは分かっているつもり。
0192NAME IS NULL
03/10/23 22:10ID:C9Vx+vuD0193NAME IS NULL
03/10/23 23:04ID:???かわいそうな経験だな・・・。
0194NAME IS NULL
03/10/24 03:26ID:???『なんかpostgres本が原因でpostgres(ユーザ)の質が落ちてるという発言にたいして
異常にきれて反論しているやつがいるけど、・・・」
>158
『・・・
本のレベル低->ユーザレベル上がらん
これはアグリーね。
でも、
ユーザレベル低 ->開発レベル低
ってのは一般論すぎて、PostgreSQLにはあてはまらんだろうと。
・・・』
出版社は関係ないよ。
0195NAME IS NULL
03/10/24 04:00ID:???出版関係者でつか？
本のレベルが低いのは出版社が原因だろ！
マニュアルと同じような内容の本を平気で出版してるからな。
孫引きを確信犯でやってる糞出版社もあるしなｗ
0196NAME IS NULL
03/10/24 05:27ID:???本のレベルというよりDBの基礎がわかってないのにいきなりマニュアル本で
Postgresいじるからでは？
0197NAME IS NULL
03/10/24 05:51ID:KPo1vWeD0198NAME IS NULL
03/10/24 08:13ID:???0199
03/10/24 08:30ID:NWwcJvkbGROUP BY文が実用に耐えないほど、遅い。
0200NAME IS NULL
03/10/24 09:04ID:???0201
03/10/24 09:06ID:ESRhBeXa0202これ？ EJB って。
03/10/24 09:07ID:ESRhBeXaEJBとはEnterprise Java Beansの略です。サーバーサイドのコンポーネント技術の仕様です。
EJBにはデータｰベースへの接続、トランザクション処理、リモートアクセスなどの機能が
すでに実装されているので、開発者はビジネスロジックのみに集中することができ、
開発効率を向上することができます。さらに、EJBはコンポーネント技術であるので、
一度作ったコンポーネント（部品）の再利用が容易にできるというのも大きな特徴です。
0203NAME IS NULL
03/10/24 09:11ID:???0204NAME IS NULL
03/10/24 09:24ID:ESRhBeXa0205NAME IS NULL
03/10/24 15:07ID:Xl9YBD0Cこれどっかで見たな、どこだっけ？
0206NAME IS NULL
03/10/24 15:36ID:bwutrtPg使うもんだから、中小には元々要らないものなんだよな。大企業は oracle 使うだろうし、Mysql, Postgresql は存在意義ないんだよ。
0207NAME IS NULL
03/10/24 15:47ID:???ふむ、たしかに>>206のいる企業は極小企業だろうな。
0208NAME IS NULL
03/10/24 16:20ID:???0209NAME IS NULL
03/10/24 16:28ID:???yahoo.comのバックエンドＤＢはMySQLですがなにか？
0210NAME IS NULL
03/10/24 16:36ID:???0211NAME IS NULL
03/10/24 19:40ID:???ほほう。
Updateが無ければDBは要らないのですか。
勉強になりまちた。
0212NAME IS NULL
03/10/24 21:26ID:???127,129,132,135,136,139,142,145,153,154,156,
160,165,167,169,172,176,185,190,192,195,206
どれが一番燃焼した？みんなで投票しよう。
0213NAME IS NULL
03/10/25 01:19ID:???アァ、助ケタマエ
0214NAME IS NULL
03/10/26 07:33ID:???212が入ってないぞｳﾞｫｹ
0215NAME IS NULL
03/10/26 12:54ID:ghlYEt5G0216206は大変お利口さん
03/10/26 12:55ID:???ほほう、DBはデータの更新に使用するものなのね？なら、蓄積とか検索は用途外なんだね？
# 勉強し直してこいよ、幼稚園から
0217NAME IS NULL
03/10/26 13:54ID:RsaU+5oG0218NAME IS NULL
03/10/26 13:59ID:RsaU+5oG全然やれる。むしろデータベースの管理費用やデータベースのバグやドライバの問題で悩むコストの
方が高くなる真実に気づかないデータベースマンセーはイラネってこった。
0219NAME IS NULL
03/10/26 14:03ID:???仕組みも自前で用意すんの？大変そう...
0220NAME IS NULL
03/10/26 14:11ID:RsaU+5oGOracleもデータベースの内部構造まで理解して最適化をきっちり行わないと遅い。
最適化するのにプログラム書くのにそう変わらない時間かかる。
そして導入や管理に面倒ばかりかかるんだよ。
「データベースありき」じゃダメ。テキストファイル置いておく方法も十分使える。
0221NAME IS NULL
03/10/26 14:22ID:L0aDuVkKつまり、更新がまったくなくて参照のみだとしても、要件しだいで
データベースが有効な場合はあるって言っているんだよな？
たしかに、データをロードするのと大して変わらない程度の
コストの処理を一発やってお終い、ならわざわざデータベース
使うのはバカだけどさ。
0222NAME IS NULL
03/10/26 14:28ID:RsaU+5oGそうだな。自力で速くできる云々ってなことじゃなくて、
単に規模の問題で、あとインデックス張るほどの速さが本当に求められているのか、を考えなきゃいけない。
0223NAME IS NULL
03/10/26 15:44ID:???0224NAME IS NULL
03/10/29 12:59ID:???0225NAME IS NULL
03/10/29 20:33ID:???書き込みないならmysqlでぜんぜん問題ない。
フロントのservletで一度読み込んだらキャッシュすればいい。
そうじゃないと、複数のフロントエンドにいちいち設定なんか
やってられん。
0226NAME IS NULL
03/10/31 16:12ID:s/EHqMeQ0227NAME IS NULL
03/10/31 16:38ID:???複雑な検索やインデックスの利用など、RDBMSを使うことで得られる利点は
多いと思うが。
全部自分で作り込むってんなら別だけど。
0228NAME IS NULL
03/10/31 18:13ID:???DB v.s.テキストファイル
のスレになったんですか?
oracleかテキストか、他のフリーDBなんぞ死ね
っていうoracle厨房の煽りにしか読めんのだが。
少なくとも釣りにはなってない。
0229NAME IS NULL
03/10/31 21:00ID:???0230NAME IS NULL
03/11/02 05:02ID:pq4ERWwSそうだね。
しかしなぜ長い コンピュータの歴史の中で
データベースがOSの標準の機能として付けられてないのかといえば、
必要なシーンが無かったからだ。
必要でもないのにデータベースありきな香具師を漏れはダメだといいたい。
0231NAME IS NULL
03/11/02 09:45ID:MejbHsV2「必要でもないのにデータベースありき」な主張している香具師なんて
ここにはいないように思えるが。
>しかしなぜ長い コンピュータの歴史の中で
>データベースがOSの標準の機能として付けられてないのかといえば、
>必要なシーンが無かったからだ。
OS/400とかBeOSとかLonghornとか。
VMSのRMSとかUNIXのdbmだってDB機能と言えるだろうし。
0232NAME IS NULL
03/11/02 11:41ID:???単にソフトウェアとしてのレイヤーが違うだけだろ。
アンタ、本当に技術者か? RDBMSの歴史を知ってて言ってるのか?
0233NAME IS NULL
03/11/02 12:07ID:bJ+I/lpv0234NAME IS NULL
03/11/03 00:24ID:???0235NAME IS NULL
03/11/03 21:16ID:???日本での普及に十分貢献したと思うんだけど....
インストール方法とか、アプリ(PHPなりJavaからなり)からの使い方もよく
書かれているし....
このスレの住人の中では、あの本は良書という扱いではない?
ただし、たしかに「手段」にかたよっているとは思う。
・DBの本質(RDBMSのプロダクトに関わらず、DB設計、運用について)に対して、
「PostgreSQL なら、こういうとき、どうする」
という記述がほとんどない。
まぁそういうことにぶち当たる人は、RDBMSのプロダクトに関わらない立場から
解説されているような本をさがすのだろうが...
煽りではなく、みんなの意見が聞きたいです。
0236NAME IS NULL
03/11/03 21:27ID:???以上。終了。
Oracle対PostgreSQLがなんでPostgreSQL本の内容批判にまで
いきつくのかわからん。そういう議論をしていた奴は
PostgreSQLのソース覗いているとか嘘いったばっかりに
クロスファイアー浴びて退場してしまった。
これ以上蒸し返すは無駄だからやめよう。
0237NAME IS NULL
03/11/09 02:37ID:TT/5XzTnスケールに対しての柔軟性については、商用の方が圧倒的に優れています。
オープンソースDBにするか、商用DBにするかを判断する能力が重要になってくる
と思います。
0238NAME IS NULL
03/11/09 04:24ID:???１，OracleとPostgreSQLで喧嘩なんてSybaseの立場がないだろがボケぇ。潰れそうだからってなめんなよ！
２，Oracle触ってみたいんで、誰か貧乏なおいらにもかしてくだちい。
0239238
03/11/09 04:25ID:???Sybaseに喧嘩売るのはMySQLの仕事だものね。ごみんよ。
0240238
03/11/09 04:27ID:???会社にひとりぼっちなんだよぉおおおおお。
誰かあいてしておくれよぉおおお。
0241NAME IS NULL
03/11/09 14:57ID:???0242NAME IS NULL
03/11/09 15:45ID:???ライセンスの縛りぐらいだと思った。
PDFのマニュアルもそろってるし（あんな大量のマニュアルは頭から読めない
けど。）紙マニュアルでぼってた時代に比べればだいぶ環境はよくなったよな。
0243NAME IS NULL
03/11/11 22:03ID:???データベースの性能うんぬんよりも、Oracleの保守料金に値するデータ（業務）であるかどうかだと思います。
なんて思うと、フリーDBでもMSAccessでも十分だったりするのがゴロゴロしてたり。
大企業はコストよりも信頼性重視が強くて、フリーDBはあまり相手にしてくれませんけどね。
0244NAME IS NULL
03/11/12 00:05ID:???「フリーDB」で安心して任せられるSIerが皆無な現状じゃあねぇ。
0245NAME IS NULL
03/11/12 00:10ID:???昔、１０年くらい前
UNIX系ソフト開発でgccを使うかどうかって会社幹部が議論してた。
いままで通りSUNやSGIのコンパイラを買って使うかgccに移行するかなんだけど、
結局、製品にバグが発生したときにgccでは責任を取ってもらえないので却下だった。
そもそもコンパイラのバグで損害が発生したとして、
それを証明してSUNやSGIと訴訟して勝てるのかなんて考えず、
ただフリーは不安、買ったものなら保証があるなんて雰囲気でしか判断していないんだけどね。
企業のいう信頼性って"高価格の保証書"が存在しているってことなんだよなあ。
保証書の中身はどうでもいいらしい。
その会社はかなりデカかったので今でも存続している。
ソフト開発からはだいぶ前に撤退しているけど。
0246NAME IS NULL
03/11/12 00:17ID:???大企業でもフリーDB使ってるんじゃない？
PostgreSQLじゃないけど、MySQLなんかYahooのバックエンドとかで動いてるじゃん。
あれってどっかSIが入ってるの？それともYahooのエンジニア?
あと、名前はだせないがいくつか大企業(1部上場企業っていうことで大企業ということにしてちょうだい)で
実際にMySQLやPostgreSQLは使われているのを知っているよ。
0247246
03/11/12 00:19ID:???「あまり」相手にしてくれないってことか > 243
全然相手にしていないといっているのではなくて程度問題ってことね。
0248NAME IS NULL
03/11/12 00:32ID:???自分ンとこでできるリソースを持っているところはそれなりにちゃんとできると
思うけど、それを外部から調達しようと考えた場合が問題だってことだな。
やっぱり「PostgreSQL使えます」レベルのところに頼むのは不安があるよ。
0249NAME IS NULL
03/11/12 00:56ID:???そこそこでかい会社が自前でシステム構築できるのに、
SIが出来ないってのも変だよなあ。
そこそこでかい会社といっても、エンジニア主体の会社じゃないかぎり、
自前のレベルってそんなに高くはないはずだけどねえ。
ただ単にSI会社のレベルが低いってわけではなくて、
その程度の仕事にそんなにコストはかけられないってことで
SI会社の出番がないのかね。
このあたりはフリーDBのビジネスという観点から非常に興味深いね。
0250NAME IS NULL
03/11/22 02:24ID:???0251NAME IS NULL
03/12/26 22:21ID:1/Y+KCCOSybaseも悪くはないよ。
サポセンはアフォーだがLinux版の性能としては決して悪くない。
0252NAME IS NULL
04/01/06 14:52ID:GYPHZUsW一体なんですか?
■ このスレッドは過去ログ倉庫に格納されています