X
トップページ⇒DB＠2ch掲示板
1002コメント288KB
MySQL vs PostgreSQL Part2
■ このスレッドは過去ログ倉庫に格納されています
0001NAME IS NULL
垢版 |
2005/08/03(水) 04:43:20ID:j7oDtJr2
同じオープンソースRDBMSとしてのMySQLとPostgreSQLを語ろう。

どちらが良い・悪いの宗教論争ではなく、漏れたちユーザにとってのそれぞれの使い所を見出そう。

前スレ

MySQL vs PostgreSQL
http://pc8.2ch.net/test/read.cgi/db/1056943680/l50
0421NAME IS NULL
垢版 |
2008/07/14(月) 23:34:21ID:???
別にココはマ板でもない点について
0422NAME IS NULL
垢版 |
2008/07/15(火) 09:15:07ID:???
>>419
mixiはCentOSじゃなかった?

> 確かにfedoraでもdebianでもカーネルパニックとかには遭遇した事ないけどサ。

ああいうとこはkernel入れ替えてるんじゃないかな。

>>420
おまえ、何の情報も持ってないんだなぁ...
0423NAME IS NULL
垢版 |
2008/07/19(土) 02:15:38ID:???
>>422
> おまえ、何の情報も持ってないんだなぁ...

>>418 のアホさ加減を示すのにこれ以上なんか情報がいるのか？

もう十分だと思うけど。
0424NAME IS NULL
垢版 |
2008/07/19(土) 14:05:24ID:???
何が十分なんだよ。

相手が泣き叫んで許しを請うまでひたすら続けろ。
0426NAME IS NULL
垢版 |
2008/07/22(火) 23:23:33ID:LtKhkX2i
他人を貶す前に己の貧しさを知れ！
聞き囓った様な話じゃなくて、
本質的な内容にしようぜ。
0427NAME IS NULL
垢版 |
2008/07/23(水) 00:24:03ID:???
そう思うなら、まずお前からネタ振れよ。
0429NAME IS NULL
垢版 |
2008/07/23(水) 22:58:31ID:???
ネタが無いなら黙っとけよ。
0430NAME IS NULL
垢版 |
2008/07/26(土) 21:33:51ID:???
>>429

そう言いつつネタ出せないんだから、つまらんやつだなぁ。
じゃあなんかネタふるか。
Drizzleどうよ?
0431NAME IS NULL
垢版 |
2008/08/20(水) 14:21:51ID:be7jHo9Q
今後を見ていくとPostgreSQLでおｋ？
0432NAME IS NULL
垢版 |
2008/08/20(水) 15:57:30ID:???
今も昔もWorldWideではMySQL
0433NAME IS NULL
垢版 |
2008/08/20(水) 16:19:27ID:???
昔はSQLの制限考えるとMySQLはありえなかったけど
今はどっちでもいいな、むしろMySQLのがサポート広い？
でもPostgreSQLかなあ。
0434NAME IS NULL
垢版 |
2008/08/21(木) 03:48:21ID:Kn230A2n
MySQLはライセンスがうるさそうってか、
GPLってみんなあんまり意識してなさそう

世界じゃMySQL（CMSに採用されすぎｗｗｗ）
日本じゃPostgreSQL（MySQLに追いつかれる）

って感じ？かな？
0435NAME IS NULL
垢版 |
2008/09/13(土) 05:19:48ID:???
今度テラレベルのシステムを作ることになりそうだ
PostgreSQLににしようか本気でまよっている
0436NAME IS NULL
垢版 |
2008/09/13(土) 11:06:57ID:???
>>435
PostgreSQLじゃVACUUMが追いつかない
製品選定前に前もって性能テストしたほうがいいよ
0437NAME IS NULL
垢版 |
2008/09/13(土) 11:58:12ID:???
>>434
サーバサイドに関して言えば GPL である事は殆ど問題にならないよ。
少なくとも GPL v2 までは意識する必要はあまり無い。

GPL はバイナリを入手した人に対してソースも入手可能にしないと
いけないというルールだけど、サーバプロダクトはバイナリを配布
するわけじゃないから、ソースも公開する必要は無い。
0438NAME IS NULL
垢版 |
2008/09/13(土) 12:19:59ID:???
そんな自分の仕事の範囲で語られても...。
0439NAME IS NULL
垢版 |
2008/09/13(土) 13:11:53ID:???
データベースサーバの範囲なら大体オッケー...。
0440NAME IS NULL
垢版 |
2008/09/13(土) 14:38:58ID:???
相当狭い世間しか知らないようだ...。
0441NAME IS NULL
垢版 |
2008/09/13(土) 15:16:51ID:???
ここは自己分析をする場所じゃないよ...。
0442NAME IS NULL
垢版 |
2008/09/13(土) 15:28:50ID:???
話を分かり易くする為に前提条件を付けて話題を限定しているのに、
狭い世間しか知らないってどんなだw
0443NAME IS NULL
垢版 |
2008/09/13(土) 19:24:40ID:???
>>442
その限定ってまさかデータベースサーバの範囲とか言う間抜けなことを
言ってるんじゃないよな？
0444NAME IS NULL
垢版 |
2008/09/13(土) 20:34:29ID:???
間抜けと話すと会話が噛み合ねえな...。
0445NAME IS NULL
垢版 |
2008/09/13(土) 21:11:50ID:???
とりあえず、437が大馬鹿ということだけは理解
0446NAME IS NULL
垢版 |
2008/09/14(日) 00:21:18ID:???
>>436
レスありがとう
データが大量になりそうなテーブルは、インサートオンリーなんだ
VACUUMが必要な仕組みは、イヤだなぁ、と感覚的には思ったんだが、
インサートがメインだから、テーブル指定でVACUUMすれば問題ないかなぁ。と楽観的に考えている

たしかに性能テストした方がいいね
0447NAME IS NULL
垢版 |
2008/09/14(日) 02:22:36ID:???
>>446
インサートオンリーのテーブルもVACUUMが必要って知ってた？
http://www.postgresql.jp/document/current/html/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND

パーティション機能をつかってテーブル分割したり、
VACUUMかけるテーブルを日ごとにローテーションしたり
運用で工夫することになると思うよ。

技術的に不可能なわけじゃないから止めはしないけど、
がんばってね。
0448NAME IS NULL
垢版 |
2008/09/14(日) 09:59:45ID:???
8.3ではVACUUM頻度が劇的に落ちているから、それほど神経質になる必要は
あまり無いと思うけどなぁ
0449NAME IS NULL
垢版 |
2008/09/14(日) 10:42:08ID:???
そもそも「テラレベルのシステム」って言う俺たちには知り様のない
システムの話だから、>>435 に性能テストしてもらうしかない。

Vacuum 以外に落とし穴がないわけじゃないし。
0450NAME IS NULL
垢版 |
2008/09/14(日) 12:02:00ID:???
PostgresみたいなフリーRDBMSは運用周りのサポートが弱いからねぇ。
使いはじめは考慮しなければならない部分が少ないから逆に楽なんだけど。
0451NAME IS NULL
垢版 |
2008/09/14(日) 13:48:00ID:???
>>435です
2^32≒20憶トランザクションごとにトランザクションＩＤが周回してしまうから
全テーブルVACUUM必要なことは知らなかった

Oracleで４テラくらいのつくったときは、特に問題なかったんだ
それが４年くらい前だった

それからソフトもハードも進化したから（750玉なんてあるし）
PostgreSQLやMySQLとかでもいけるんじゃないかと思ってさ

実証実験するだけで、金かかりそうだなぁ

>>449
＞Vacuum 以外に落とし穴がないわけじゃないし。
バックアップ・復旧周りが実は恐れている
0452NAME IS NULL
垢版 |
2008/09/14(日) 14:42:44ID:???
> 2^32≒20憶トランザクション

2^32 は約 40億だし、>>447 のリンク先にもそう書いてあるんだが...。

> これを防ぐためには、すべてのデータベースにあるすべてのテーブルを
> 少なくとも20億トランザクションごとにバキュームする必要があります。

と混同したのかも知れないけど、もう少し落ち着いてドキュメントを読む
癖つけたほうがいいぞ。

> 実証実験するだけで、金かかりそうだなぁ

金もかけずににちゃんのアドバイスで荒波に立ち向かうと言うスリリング
な人生を選択してもいいと思うけど。(w
0453NAME IS NULL
垢版 |
2008/09/14(日) 16:59:16ID:???
>>451
それこそ素直にOracle使うような案件なんじゃ……。
世の中の案件の80%はMySQL/PostgreSQLで済むと思うけど、
これは残り20%の範疇のように思う。
0454NAME IS NULL
垢版 |
2008/09/15(月) 17:55:03ID:???
あと、PostgreSQLは定期的にvacuum fullしないとSELECT性能が劣化するから注意。
0455NAME IS NULL
垢版 |
2008/09/15(月) 20:29:30ID:BunTDGAt
業務の関係でこれからPHPを勉強することになりました。
それで今アマゾン等でPHPの書籍を探しているところです。
仕はでPHP＆postgreSQLの組み合わせなのですが、アマゾンや書店で
見つかるのは大概PHP＆MySQLの組み合わせのものばかりです。
MySQLとPostgreSQLの違い(PHPとの連携する上で)がまだわからないのですが、
MySQLのほうのやつを買ってもポスグレ案件で役立ちますか？
(PHP初心者ですみません)
0456NAME IS NULL
垢版 |
2008/09/16(火) 22:00:19ID:???
>>455
・貴方のレベルにもよる
　文章から察するに１〜３年目くらいに見えます。
　（違っていたら申し訳ない。）
　他の言語を複数習得している（それぞれ１年以上経験ある）レベルか
　他の言語もやったことあるが、マスターしているとは言えないレベルなのか

・新規なのか既存なのかで判断が異なる
　新規案件でPHPで業務の基盤周りから組むのと
　既存案件で、すでに基盤はしっかりしているのと
　で、参考になる書籍はことなると思う
　（PEARはつかっているかとか）


マンモス本でよいんじゃないでしょうか
今はPostgreSQLのことかいていないんでしたっけ？
0458NAME IS NULL
垢版 |
2008/09/21(日) 09:48:08ID:???
>>454
それは昔のバージョン
今はバキュムしなくてもほとんど劣化なし
0459NAME IS NULL
垢版 |
2008/09/22(月) 10:16:28ID:???
そっか。少なくとも 8.1 まではそうだったけど、その後改善されたのかな。
0460NAME IS NULL
垢版 |
2008/09/22(月) 11:09:19ID:???
8.3で改善されました
0461NAME IS NULL
垢版 |
2009/03/01(日) 11:14:17ID:???
単純にオートvacuumしてくれるだけで、vacuumしなければ、フルスキャンが遅くなっていく点は変わってないんじゃね？
0462NAME IS NULL
垢版 |
2009/03/03(火) 02:06:41ID:???
>>461
つ ttp://itpro.nikkeibp.co.jp/article/COLUMN/20070409/267852/
0463NAME IS NULL
垢版 |
2009/04/22(水) 00:33:38ID:???
今度、オラクルで作っているシステムの換装があるんだけど、
そのままオラクルでいくか、MySQLやPostgreSQLを使うか本気で
迷っています。

データベース構造としては、親子関係の2階層のテーブルが
全部で１０個くらいなんだけど、データ数がべらぼう。

1億は余裕で超えます。
理由は、格納するものは使用しているユーザーの操作ログだからです。
１つのボタンを操作するだけで、さまざまなファイルやデータを触るから、
それで、何十レコードにもなってしまいます。

10億とか行ったら、さすがにオラクル以外の選択肢はないんでしょうか？

また、性能評価って言いますけど、入札前に高価な想定するH/Wを
購入してまで性能評価ってやります？

検索リアクションタイムに制限があるけど、それをどう担保しようかが
最大の悩み。

みなさんは、実機相当のシステムで、同じ環境でデータベースを何億
も入れて性能調査やってるのでしょうか？

特にコンサル業界の人に聞きたい。
0464NAME IS NULL
垢版 |
2009/04/22(水) 00:35:12ID:???
MySQLは、テーブル１つに１ファイルですよね？
テーブルのレコードが多ければ、それだけ検索するたびに、
ファイルオープンが発生するから、MySQLは遅いんだ。

この認識あってる？
0465NAME IS NULL
垢版 |
2009/04/22(水) 00:45:46ID:???
ログなんか大して参照しないだろ
するとしても参照するデータとしないデータに偏りがあるだろ
期間か何かで切り分けろよ
そうすればどれでもいける
0466NAME IS NULL
垢版 |
2009/04/22(水) 00:55:00ID:???
ファイルオープンしないDBってなによ
0467NAME IS NULL
垢版 |
2009/04/22(水) 11:01:41ID:???
そもそも、MySQLがこの先も生き残っているのかという問題が
MySQLはOracleに殺されそうだな
0468NAME IS NULL
垢版 |
2009/04/22(水) 11:05:13ID:???
NetBeansに対するEclipseのように、MySQLにも有料化したらPostgreSQLに流れるだけなので
存続させるために無料のライセンスは続けるんじゃないかな。
サポートのライセンスは今でも有料なんだし。
0469NAME IS NULL
垢版 |
2009/04/22(水) 13:24:01ID:???
Orcaleの得意技の飼い殺しというのが今一番懸念されているわけで。
0470どちらかというとSです
垢版 |
2009/05/29(金) 15:48:06ID:9rXfEjjy
>>463
板違い,コンサルでもない...
マニアックすぎて鼻で笑われるとおもいますが、
作りと開発者の技量にもよると思うけど
商用DBだけどCache' と言うのがあります..
内部(M)言語ガリガリではなく、
SQLアクセスで１億以上はさばけてます..
それぞれのアプリの条件にもよるので軽くとは
言い切れませんが、

10億はテストした事ないけど...

動作にOracleほど高価なH/Wはいらないと思います。
性能調査する価値はあるかも...

いまさらMっていわれるのがおち..ですかね...
DB自体くせもあるし..


0471NAME IS NULL
垢版 |
2009/05/29(金) 20:56:42ID:???
そりゃねぇ、いくらIMSがそこらのRDBMSより速いとは言ってもやっぱり「いまさらIMS」だしねぇ。
10億くらいならPostgresでもイケるし。
0472NAME IS NULL
垢版 |
2009/05/30(土) 00:40:23ID:???
そりゃねぇ、から語り出すとは通ですな。
0473NAME IS NULL
垢版 |
2009/07/02(木) 21:23:06ID:l4DZdBP4
age
0474NAME IS NULL
垢版 |
2009/10/27(火) 07:48:04ID:iq32s6Ha
>>471

MySQLは何億くらいまで、いけるんでしょうか？
あと、質問があと先になりましたが、10億の単位は何でしょうか？

よろしくお願いします。

0475NAME IS NULL
垢版 |
2009/10/27(火) 15:17:45ID:???
円に決まってるだろ
0476NAME IS NULL
垢版 |
2009/10/27(火) 19:22:39ID:???
甘いな
最近は元でしょう。
0477NAME IS NULL
垢版 |
2009/10/28(水) 10:36:31ID:???
ウォン以外考えられないニダ
0479NAME IS NULL
垢版 |
2010/04/01(木) 23:57:05ID:???
indexなしでレコード追加してくだけなら何十億でも平気だろうな
10億を細かく参照やら分析するんならRDBMSやめれと思う
0480NAME IS NULL
垢版 |
2010/04/30(金) 23:59:29ID:KOHIXyIB
このスレ、死んでるやん？ｗ
ちょっと調べてみたけど、機能的にもコスト的にもPostgreSQLの一人勝ちじゃん

MySQLは今までたくさんの人が使っていたっていう惰性で情報が多いのと
ほんのちょっぴりの軽さだけが売り
ちょっとでもGPLを逸脱すると商用ライセンス

PostgreSQLはほぼLinuxでしか使えてなかったのが
Windowsにも進出してトランザクションもありーので完全にタダ

みんなでPostgreSQLに移ろうぜ
俺はPostgreSQLに移るよ
0482NAME IS NULL
垢版 |
2010/05/01(土) 10:04:04ID:fQ97Oi/l
>ちょっと調べてみたけど、機能的にもコスト的にもPostgreSQLの一人勝ちじゃん

さすがに、「性能」までは言わないか。
0483NAME IS NULL
垢版 |
2010/05/01(土) 10:21:14ID:???
PostgreSQLのシェアはもうちょっと上がってもいいと思ってる
MySQLだけは危険だ
0484NAME IS NULL
垢版 |
2010/05/01(土) 14:52:52ID:???
手元で動かしていると、MySQLのほうが性能が良いのはCPU1個のときだけで、
2-4 個を越えるとPostgreSQLのほうが圧倒的に伸びが良いんだが。
0485NAME IS NULL
垢版 |
2010/05/01(土) 16:25:57ID:???
そんなもん
MySQLが速いのはCPU1〜2個
CPU4〜8個はPostgreSQLが速い
それを超えるとOracleが圧倒的に速い
0486NAME IS NULL
垢版 |
2010/05/01(土) 17:38:36ID:???
>>485
へー。やっぱり想定しているハードウェアの規模が違うのかもね。
ただ、今や普通にCPUを買っても普通に4コアとかになることを考えると……？
0487NAME IS NULL
垢版 |
2010/05/01(土) 18:06:57ID:???
そこでMySQL InnoDB Pluginですよ
0488NAME IS NULL
垢版 |
2010/05/02(日) 09:19:17ID:???
MySQLはもう過去の遺物でいいだろ
人気に胡坐かいてた罰だ
0490NAME IS NULL
垢版 |
2010/05/03(月) 10:20:31ID:???
>>484
MySQLの場合、大規模案件では単一マシンの強化ではなくクラスタ化という方向だしね。

>>485
OracleはCPUの数でライセンス料が違ってくるだけあって、スケーラビリティあるよなぁ。
0491NAME IS NULL
垢版 |
2010/05/04(火) 13:58:39ID:???
>>485
>>486

公平に書くとMySQLのCPUスケーラビリティはバージョンと
ストレージエンジンに依存するからそんな単純ではない。

MySQL5.1までは確かにCPUコア数に対するスケーラビリティは低かったが
5.0でもInnoDBなら4程度まではなんとかなっていた。
5.4からはgoogleパッチでInnoDBのスケーラビリティは16くらいかなり向上した。
先のMySQLカンファレンスでは5.5で32コアまでいくと報告されたらしい。
MyISAMのCPUスケーラビリティはあがらんだろうね。性能もInnoDBに負けていくようだ。

PostgreSQLは8.1と8.2で劇的にスケーラビリティ向上で8.1で16程度、
8.2で32程度になった。しかしここからは先は難しいそうだ。

Oracleはコア数でライセンスかかるから論外。リニアで性能向上しない限り
コストパフォーマンスは悪いってことになる。
貧乏人はスケールアップよりスケールアウトを目指すべし。
0492NAME IS NULL
垢版 |
2010/05/04(火) 16:22:48ID:???
「公平に書くと」とあるのでツッコむが、MySQL 5.4 も 5.5 も GA としてはリリースされて
いないようなので、開発中のバージョンの性能を持ってきても、比較にならないんじゃないの？
バグもあるだろうし、バグを潰していく中で追加の排他制御が必要になるかもしれないし。
0493NAME IS NULL
垢版 |
2010/05/04(火) 18:47:59ID:???
MySQLは正式版の5.1ですらまったく安定してないから。

http://pc11.2ch.net/test/read.cgi/db/1258928470/835-
ここで問題になってるバグは5.1.20で発覚したものらしいから正式版のバグじゃないが、
レスに5.1のバグフィックスが3500とか書いてある。

CPUのスケーラビリティはPostgreSQLが先に対応して、今MySQLが追いかけてる。
安定性については誰がどう考えてもピーーーー(自主規制)だろう。
0494NAME IS NULL
垢版 |
2010/05/05(水) 17:40:40ID:cHvVY/HE
この↓ベンチマークテストの結果ってどう読めばいいの？
http://www.thinkit.co.jp/cert/article/0603/10/5/3.htm

MySQL＋MyISAMエンジンはトランザクション機能を持ってないから速い、ってことは
どういう場面で使えば有利になるの？
その一方で、PostgreSQLはどういう場面で使えば有利になるの？
教えてエロい人
0497NAME IS NULL
垢版 |
2010/05/05(水) 18:11:37ID:???
自分でプログラム書いて測定してみるのが一番
0498NAME IS NULL
垢版 |
2010/05/16(日) 08:47:19ID:???
Postgreの権限管理周りはクソ
最近になってようやく揃ってきたけど・・・

Database単位とかSchema単位で参照権限うまく管理できねーとか
笑うしかない

あと何でＤＢ作る度にデフォでpublicに登録されるん？
アホなの？
0499NAME IS NULL
垢版 |
2010/05/16(日) 11:16:00ID:???
>>498
MySQLはどうなってるの？ スレタイ読め。

> Database単位とかSchema単位で参照権限
やっと9.0で機能が入る予定。確かにめんどくさかった。

> あと何でＤＢ作る度にデフォでpublicに登録
スキーマ修飾できるし、search_path を設定すればデフォルトも変更できる。
これに関しては PG に全く落ち度はないと思うぞ。
0500NAME IS NULL
垢版 |
2010/05/16(日) 11:55:34ID:???
>>499
ＭｙＳＱＬと比べて糞って言ってるつもりだが
書かないといかんのなら・・・すまなんだ

権限周りはMySQLだとＤＢ>tableって階層がはっきりしててGRANTで簡単に管理できるけど
Ｐｏｓｔｇｒｅは9になってやっとDB毎の権限対応でしょ・・・
PGはユーザがロールに統合されたりそこらへんの管理でポリシーを感じないんだよね

ほかのＤＢでもそうだど権限確認してログインユーザなりロールなり作る訳だが
PGは細かいなら細かいで方向性を持たせたら使いやすいのにって感じ
後で設定できるからいいだろって問題でもないと思うんだよね。

publicっていってるのはGRANTとかで使うPUBLICのことね
デフォルトだとCREATE DATABASEした直後、ログイン権限のあるユーザなら
新規作成したＤＢに入れちゃうじゃん
それってどうなのってこと

PＧは最近触り始めたので誤りがあったらごめんなさい
0501NAME IS NULL
垢版 |
2010/05/16(日) 12:17:29ID:???
標準SQLではDBとテーブルの間にスキーマの概念があるのだが、MySQLには無い。
標準SQLではユーザとグループは、ロールとして統合された。ロールのほうが柔軟性が高いデザイン。
申し訳ないが、MySQLが「ふつう」だとは思わないほうが良いよ。
Postgres はこれまで手間を減らすような機能は提供してなかったものの、設計そのものはより「正しい」と言える。

ココから先は単に PG の使い方だが、
publicスキーマに関しては REVOKE ALL ON SCHEMA public FROM public; で権限は剥奪しておける。
ログインに関しては pg_hba.conf のほうで制御するようになっている。
ぱっと見「アホなの？」と思うようなことはさすがに開発者も気づいているだろうから、少しは調べてみると良い。
0502NAME IS NULL
垢版 |
2010/05/17(月) 10:33:01ID:???
何でもかんでも調べもせずにデフォルトで使ってそれに文句言ってるのって滑稽ではある
0503NAME IS NULL
垢版 |
2010/05/17(月) 11:31:08ID:???
>>501
どちらかというと、MySQLのデータベース ≒ PostgreSQLのスキーマ と考えたほうがいいかも。
PostgreSQLでもスキーマのUSAGE権限は、その中に含まれるテーブルに引き継がれるから、
そこは >>500 が言っている動きに近いんじゃないだろうか。
0504NAME IS NULL
垢版 |
2010/05/17(月) 13:30:23ID:???
最近はsqliteがおもちゃっぽくて好きだなぁ。
Cで書くと速くてびっくり。
もちろんPostgreSQLが一番だい！
0505NAME IS NULL
垢版 |
2010/05/17(月) 23:38:43ID:???
sqlite使ってると、いつもPostgreSQLの豊富な関数使いたくてしょうがないです... orz
0506NAME IS NULL
垢版 |
2010/05/18(火) 23:16:51ID:cZm1F11R
すいません　いきなりmysqlにログインできなくなりました
以前も同じようにログインできなくなり、navicat liteを使って
いたのですがそちらにも接続できなくなりました
その時はOSの再インストールで解決したのですが再度同じようになりました
おそらくlocalhost3306に接続できてないのだとは思います
mysqlをアンインストールして再度インストールもしてみました
そうするとApply security settingsでエラーがでます
Error.Nr.1130 Host localhost is not alloowed to this MYSQL sever
設定などはいじってないのですがやはりOSを再度入れ直さないといけないのでしょうか？
長文失礼しました
0507NAME IS NULL
垢版 |
2010/05/19(水) 10:29:19ID:???
何でもちゃんと原因調べて適切な対処を取るようにしないと
毎回再インストールするはめになるぞ、、てかもうなってるか
0508NAME IS NULL
垢版 |
2010/05/19(水) 22:16:09ID:???
やばいなあ
2ヶ月ほど外に出たのはジュース買いに出ただけだよ顔色とか真っ白
0509NAME IS NULL
垢版 |
2010/05/20(木) 07:38:55ID:???
設定いじってないっつってもなぁ。
mysql.userテーブルが書き換わって、とあるユーザ@localhost に関するレコードが
無くなった/書き換わったんだと思うよ。

まあ、何にせよスレ違いっぽいな。

MySQL 総合 Part17
http://pc11.2ch.net/test/read.cgi/db/1258928470/
0510NAME IS NULL
垢版 |
2010/08/01(日) 18:09:56ID:bWT/bAf1
で　どうなったの？
0511NAME IS NULL
垢版 |
2010/08/16(月) 00:36:44ID:E3q0YRo4
技術的には関係なく、経営上の理由で、
MySQLが勝手に潰れてPostgreSQLが勝利しそうな感じ
0512NAME IS NULL
垢版 |
2010/08/16(月) 06:05:57ID:???
MySQLの世界での普及度合は半端じゃないから
もし5.5で開発打ち止めになったとしても
MariaとかDrizzleなどの互換プロダクトがシェアを維持するんじゃないかな
Linuxとは状況が違うのはわかっているがRHL、FedoraからCentOSが出たみたいに、
結局FreeBSDは表舞台にでれなかった。
書いてる俺はポスグレ派
0513NAME IS NULL
垢版 |
2010/08/16(月) 11:49:22ID:???
CentOSの意味解っていってるのか
あれはRHELからロゴ外してそのまま配布してるだけで互換プロダクトとかそんなレベルではない
本家が無くなったらCentOSも無くなる
0514NAME IS NULL
垢版 |
2010/08/16(月) 20:03:18ID:???
ついにオラクルがOpenSolaris潰しが始まった
近いうちにMySQLも同じようになりそうな予感
0515NAME IS NULL
垢版 |
2010/08/17(火) 04:49:05ID:???
いやいやCentOSの話と違うくらいわかってる。
MySQLがクローズソースになってもMariaとDrizzleがあるって話だ。
ポスグレがこれからMySQLなみに普及するとは思えない。
DBなんてどうでもいいプログラマがMySQL互換DBがあるのにわざわざポスグレに移ると思うか。
世の中DBなんてどうでもいいだよ。動けば。そんで動いたらもういじりたくないんだよ。
0516NAME IS NULL
垢版 |
2010/08/17(火) 10:07:53ID:???
その互換DBの存続の心配してるんだろうが
0517NAME IS NULL
垢版 |
2010/08/17(火) 10:23:54ID:???
MySQL互換DBは本家が存続しないと続かないだろ
本家をちょっと改造しただけなんだからｗ
0518NAME IS NULL
垢版 |
2010/08/17(火) 10:24:47ID:???
てかDBなんてどうでもいいのかMySQL互換DBじゃなきゃ駄目なのかはっきりしろよｗ
0519NAME IS NULL
垢版 |
2010/08/18(水) 01:28:11ID:???
基本的に、本家が投げ捨てたものを引き継いで開発し続けるプロジェクトって
上手くいかないからなぁ。あと、MySQLの場合はコマーシャルライセンスが
あったのも大きかったわけだし。
0520NAME IS NULL
垢版 |
2010/08/18(水) 11:23:55ID:???
>>516
誰がいつ互換DBの心配について書いた？
>>518
ふつうのユーザやプログラマはDBなんてどうでもいいわけ。
だから手間のかかんない互換DBでOKってことだよ

つうかMySQL使ってるほとんどの奴ってレベル低いだろ
ポスグレやオラクル覚えようなんて奴いねえよ。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況