エラーメッセージも読まないのか。

>>149
それが実際に問題になるなら、Innoもフォークすることになる。
GPLの最大の特徴は、誰も排他的権利を持ち得ないことなんだから。

でも、結局はInnoDBからforkせずにFalconをスクラッチから書いたわけだしなぁ。

InnoDBってなんて読むの？
イノディービー？
もう一つはマイイザム？

好きなように読めばw

MySQLにしても、InnoDBにしても、厳密にはGPLとはちょっと違うじゃん
デュアルライセンスなんだし、Oracleなり、MySQL ABなりに御布施すればGPL免除でしょ？
MySQL Enterpriseなんて、登場した時から既にGPL制限の無いアプリだし
これからはMySQL Community ServerとMySQL Enterpriseの差が、
どんどん開いてゆくだろう事は想像に難くない

でも一番の問題は、昔はGPL汚染に躊躇してMySQLが採用されない事例を回避する為に
「MySQL ABに寄付してくれればGPL回避出来ますよ」的な意味合いのデュアルライセンスだったのに
今では、というかMySQL Enterpriseが出た辺りからだんだんと、「おまえ(Community Server)のものは
俺(MySQL Enterprise)のもの、俺のものは俺のもの」的なジャイアニズム全開なデュアルライセンス
に意味が変わったことだね

とはいえ>>147も触れてるとおり、MySQLは創始者自身がforkしたし、
InnoDBも去年forkしたExtraDBってのがあるにはある

先行きは明るくないとは思うけど、MySQLを捨てるのはまだ早いと思うよ

>>154
イノデービー
マイアイサム

>>154
いのちゃん
あいさむ

データはインサートできても
チンコはインサートできないんだなぁ

みつを

no

>>161
レプリケーション使え。

ハッカーを刺激してフリー版のMYSQLが一段と強くなると思う
gpg、ssl、appacheなどソフトはフリーのほうが優秀だよ。
それは当然であって、社内の限られた研究者が世界中のハッカーに
勝てるわけがないのね。数が違うから。

>>164
可能性としてはあるかもしれないけど、まぁないと思うよ
興味あることの実装と、それを安定して使えるようにする
というのは別物だし。
オプソの弱点のはそこだ　ともいわれているしね
コアだった開発者がどこまで集まるかはじゃないかな
＃アーキテクト含めて

>>164
そうだな、そうであればうれしいな。
でも、>>165の意見に賛同する部分が多いよ。

我侭なユーザーに怒らずに頑張れるのが金なんだよな。
MySQLも皆の為に頑張るよっていうすげぇ素晴らしい人
ばかりだったらSunすら買えなかっただろう。

2年くらい経ったらNetscape並の黒歴史入りかもな。

>>167
そうなったらいいね。
firefox並に復活してきたらいいなぁ。
でも、そん時はMySQLって名ではないのだなぁ。

サーベルタイガーあたりの名前で復活してくれ。

なくてもいい

>>169
GPLにして再配布可能にしちまえ

>>170
そのへん詳しく書かれているソースとかあったら教えてもらえるとありがたいです。
ぐぐっていろんなとこ見ても、イマイチよくわからない・・・

>>171
仕事なのでムリっすねぇ。

仕事ならoracleでも使っとけ

ライセンスに悩むのならBSDLなPostgreSQLにすべきだろうな

質問させてください。
複合インデックスを作成する際のキーの順番って関係ありますか？
またその場合はカーディナリティの高い順にするべきでしょうか？
よろしくお願いします

もしかしてスレ違いでしたか？
質疑高等スレで出直してきます。

外部キーよりチェックの方が使う機会多いと思うのにな。

早くこのDB無くならないかなぁ

>>180

それをわざわざこのスレに言いに来る意味があんのか？
俺としては、買収前にOracle社そのものがなくなって欲しかったわ。
Oracleを盲信してるやつらがうざい。

SUNの株主がOracleへの売り渡しに抵抗しているみたいだから、
もしかしたらSunの買収話は消えるかもよ

MySQLだけOracleに譲渡とかなw

>>182
hagedo

MyISAM＋fulltextインデックスを使用して全文検索を行っているのですが、
レコードの量が増えるにつれInsertがどんどん、遅くなっていきます。
ある程度は、覚悟していたのですが、あまりにも遅く…。
今後もレコードは増え続けるのですが、どう対応してよいのやら…。

ある程度のところで、新しい全く同じレイアウトのテーブルを
作成し、そのテーブルにデータを追加していき、selectするときは、
既存のテーブルと元のテーブルをunion？

しかし、テーブルを分けてしまうと、重複レコードが…。

通常、こういった場合、どのように対応するのでしょうか？
ご教授していただけないでしょうか。
よろしくお願いします。m(_ _)m

http://www.atmarkit.co.jp/news/200905/14/mysql.html
よし、まだまだ大丈夫

更新はときどきまとめて行うことにして
1) fulltextインデックス削除
2) INSERT
3) fulltextインデックス作成
とか？
いろいろ制限はついてしまうけど。

単純に定期的に最適化してないってわけじゃなくて？

>>186
Falconがどうなったか思い出せ

>>186

MySQLの思いつきみたいな機能追加と変更はまともな技術者のなせる技ではない。
MySQLはmontyしかforkできないが、montyの技術力じゃ維持しつづけるのは無理。
よって終了

>>191
ばかだこいつｗｗｗｗ

前半は同意

10年くらい、今のバージョンのままでいいよ

機能追加は無しで、バグフィックス程度はね。

でもストアドは弱すぎない？
5.xの見てる感じだけど

MySQLを生かすも殺すもOracleの思いのままになった時点でMySQLは終了だ。
Oracleには期待するな。OracleがMySQLを生かそうとするならそれはローエンドのユーザから金をむしり取る場合だけだ。
無料という意味でのフリーウエアとしてはMySQLは終わったんだ。

モンティがforkするMariaSQLはだめだ。マイナーバージョンアップですらゴタゴタする思いつき開発しかできない奴に、
ここまでひろまってしまったプロダクトの舵取りさせたら混乱するだけ。
しかし、モンティに逆らって別プロジェクト立ち上げる人間も、それについていく人間もいないだろう。
強いてあげればGoogleくらいか。GoogleSQLとしてforkすれば移行する人間も多いだろう。しかしGoogleがMySQLを使い続けるだろうが、
それをオープンにしてメンテしつづける意味はまったくない。よってGoogleSQLはない。

つまりMySQLは終わったんだ。

トリガを使ってテーブルの更新をWEB画面に反映させることは可能でしょうか

>>199
トリガとWEBについて1から勉強しなおし