MySQL vs PostgreSQL Part2
■ このスレッドは過去ログ倉庫に格納されています
同じオープンソースRDBMSとしてのMySQLとPostgreSQLを語ろう。
どちらが良い・悪いの宗教論争ではなく、漏れたちユーザにとってのそれぞれの使い所を見出そう。
前スレ
MySQL vs PostgreSQL
http://pc8.2ch.net/test/read.cgi/db/1056943680/l50
>>498
MySQLはどうなってるの? スレタイ読め。
> Database単位とかSchema単位で参照権限
やっと9.0で機能が入る予定。確かにめんどくさかった。
> あと何でDB作る度にデフォでpublicに登録
スキーマ修飾できるし、search_path を設定すればデフォルトも変更できる。
これに関しては PG に全く落ち度はないと思うぞ。 >>499
MySQLと比べて糞って言ってるつもりだが
書かないといかんのなら・・・すまなんだ
権限周りはMySQLだとDB>tableって階層がはっきりしててGRANTで簡単に管理できるけど
Postgreは9になってやっとDB毎の権限対応でしょ・・・
PGはユーザがロールに統合されたりそこらへんの管理でポリシーを感じないんだよね
ほかのDBでもそうだど権限確認してログインユーザなりロールなり作る訳だが
PGは細かいなら細かいで方向性を持たせたら使いやすいのにって感じ
後で設定できるからいいだろって問題でもないと思うんだよね。
publicっていってるのはGRANTとかで使うPUBLICのことね
デフォルトだとCREATE DATABASEした直後、ログイン権限のあるユーザなら
新規作成したDBに入れちゃうじゃん
それってどうなのってこと
PGは最近触り始めたので誤りがあったらごめんなさい 標準SQLではDBとテーブルの間にスキーマの概念があるのだが、MySQLには無い。
標準SQLではユーザとグループは、ロールとして統合された。ロールのほうが柔軟性が高いデザイン。
申し訳ないが、MySQLが「ふつう」だとは思わないほうが良いよ。
Postgres はこれまで手間を減らすような機能は提供してなかったものの、設計そのものはより「正しい」と言える。
ココから先は単に PG の使い方だが、
publicスキーマに関しては REVOKE ALL ON SCHEMA public FROM public; で権限は剥奪しておける。
ログインに関しては pg_hba.conf のほうで制御するようになっている。
ぱっと見「アホなの?」と思うようなことはさすがに開発者も気づいているだろうから、少しは調べてみると良い。 何でもかんでも調べもせずにデフォルトで使ってそれに文句言ってるのって滑稽ではある >>501
どちらかというと、MySQLのデータベース ≒ PostgreSQLのスキーマ と考えたほうがいいかも。
PostgreSQLでもスキーマのUSAGE権限は、その中に含まれるテーブルに引き継がれるから、
そこは >>500 が言っている動きに近いんじゃないだろうか。 最近はsqliteがおもちゃっぽくて好きだなぁ。
Cで書くと速くてびっくり。
もちろんPostgreSQLが一番だい! sqlite使ってると、いつもPostgreSQLの豊富な関数使いたくてしょうがないです... orz すいません いきなりmysqlにログインできなくなりました
以前も同じようにログインできなくなり、navicat liteを使って
いたのですがそちらにも接続できなくなりました
その時はOSの再インストールで解決したのですが再度同じようになりました
おそらくlocalhost3306に接続できてないのだとは思います
mysqlをアンインストールして再度インストールもしてみました
そうするとApply security settingsでエラーがでます
Error.Nr.1130 Host localhost is not alloowed to this MYSQL sever
設定などはいじってないのですがやはりOSを再度入れ直さないといけないのでしょうか?
長文失礼しました
何でもちゃんと原因調べて適切な対処を取るようにしないと
毎回再インストールするはめになるぞ、、てかもうなってるか やばいなあ
2ヶ月ほど外に出たのはジュース買いに出ただけだよ顔色とか真っ白 設定いじってないっつってもなぁ。
mysql.userテーブルが書き換わって、とあるユーザ@localhost に関するレコードが
無くなった/書き換わったんだと思うよ。
まあ、何にせよスレ違いっぽいな。
MySQL 総合 Part17
http://pc11.2ch.net/test/read.cgi/db/1258928470/
技術的には関係なく、経営上の理由で、
MySQLが勝手に潰れてPostgreSQLが勝利しそうな感じ MySQLの世界での普及度合は半端じゃないから
もし5.5で開発打ち止めになったとしても
MariaとかDrizzleなどの互換プロダクトがシェアを維持するんじゃないかな
Linuxとは状況が違うのはわかっているがRHL、FedoraからCentOSが出たみたいに、
結局FreeBSDは表舞台にでれなかった。
書いてる俺はポスグレ派
CentOSの意味解っていってるのか
あれはRHELからロゴ外してそのまま配布してるだけで互換プロダクトとかそんなレベルではない
本家が無くなったらCentOSも無くなる ついにオラクルがOpenSolaris潰しが始まった
近いうちにMySQLも同じようになりそうな予感 いやいやCentOSの話と違うくらいわかってる。
MySQLがクローズソースになってもMariaとDrizzleがあるって話だ。
ポスグレがこれからMySQLなみに普及するとは思えない。
DBなんてどうでもいいプログラマがMySQL互換DBがあるのにわざわざポスグレに移ると思うか。
世の中DBなんてどうでもいいだよ。動けば。そんで動いたらもういじりたくないんだよ。
MySQL互換DBは本家が存続しないと続かないだろ
本家をちょっと改造しただけなんだからw てかDBなんてどうでもいいのかMySQL互換DBじゃなきゃ駄目なのかはっきりしろよw 基本的に、本家が投げ捨てたものを引き継いで開発し続けるプロジェクトって
上手くいかないからなぁ。あと、MySQLの場合はコマーシャルライセンスが
あったのも大きかったわけだし。 >>516
誰がいつ互換DBの心配について書いた?
>>518
ふつうのユーザやプログラマはDBなんてどうでもいいわけ。
だから手間のかかんない互換DBでOKってことだよ
つうかMySQL使ってるほとんどの奴ってレベル低いだろ
ポスグレやオラクル覚えようなんて奴いねえよ。 レンタルサーバに設定済みのDB使うなら
PostgreSQLだろうがOracleだろうがどうでもよくね
今時ならフレームワークのマッパー使うだろうし
なんでMySQL互換である必要があるのかと >>520
他のレス全然読めないならいちいちレスすんなよ このスレ5年も生きてるけど、
けっきょく、どうなんだ 大規模だったらPostgreSQLの方がいいと思うけど
ぶっちゃけどっちでもいいレベルだと思う >>524
>大規模だったらPostgreSQLの方がいいと思うけど
kwsk MySQLのJOINの方式はレコード数が増えるとパフォーマンスが落ちる(Nested Loop Joinしかない)
あとMySQLのレプリケーションはマスタがおかしくなると終わり
(というか面倒でリカバリに時間が掛かる) MySQLはJOINしないで読み出しばっかやるシステムだと最強なんだけどなー >>528
それならKVS最強じゃね?memcached以外にもいろいろ選択肢がある。
あと、メモリにテーブルデータ全部のっければMySQLもPostgreSQLも速いよ。
つうことでJOINなし検索OnlyでもMySQLは最強じゃないよ。
MySQL使う理由って結局ノウハウだよね
KVSだとまだ耐障害性とか未知の部分があって、
こないだのmixiみたいになることもある。 単純にJOINなし検索専用ならノウハウなんていらんだろ
慣れ、惰性だよ。
MySQL使ってる連中の99%は惰性で使ってるだけ
ノウハウなんてない。このスレみてみ
http://www.mysql.gr.jp/mysqlml/mysql/msg/15364
全員書籍執筆者なのにまともにデータバックアップもリストアもできないんだぜ。
使えてる気になってるだけ。
うわこれはひどい
ただテクニカルライターって現場で引っ張りだこの人でも新しい何かを産み出す人でもなくて
暇な人がやってるという俺の認識からすると不思議なことではない。
わかりやすい文章を書くにはプログラミングと別の才能が必要だからそれはそれで尊敬するけど
大企業なんかでちゃんとしたインフラやってる人が書くってより
中小企業の経営者やフリーランスが書いてるイメージあるな 執筆者は2極化してるよ。
評価の高い本を書くひとは所属関係なく技術レベルも高い。
糞本しか書けないひとはそれなり。
>ただテクニカルライターって現場で引っ張りだこの人でも新しい何かを産み出す人でもなくて
>暇な人がやってるという俺の認識からすると不思議なことではない。
>中小企業の経営者やフリーランスが書いてるイメージあるな
MySQLの中の人(M信さんやO野さん)も暇な人?
そうじゃない人もいるとピックアップしても反論にならんよ
そりゃまともな執筆者もいるのは当たり前なんだし
反論するなら全書籍の執筆者を調べて
大多数は忙しくて技術も完璧ってソースにしないと >反論するなら全書籍の執筆者を調べて
>大多数は忙しくて技術も完璧ってソースにしないと
中学生の夏休みはおわっただろ。早くねないと遅刻するぞ。
つうか、全員まともor全員ダメ
って2択しかできないって、頭が不自由なゆとりだよな。
>執筆者は2極化してるよ。
これ正解。
1割のすごい連中、9割の普通の連中。
執筆依頼のないお前は糞。
>>539
依頼があるボクはすごいんだ自慢乙。
ところで、お前、恥垢臭のせいで周囲から生きる悪臭公害と言われているのに
気づいているか? あまりの臭いで自分の頭まで狂ってしまうぐらいの。
その狂った頭はもう手のつけようがないけど、臭いに迷惑している周囲のため
包茎ぐらいはどうにかしとけ。包茎は治る障害なんだから。 他の人が抱いているイメージ論に対して自分の基準で完全否定するのって小学生レベルだよな まちがった
540と541が絶句するほどひどいレス __
´ ` 、
/ ィ、 \
. / / ! //!、 ヽ
l l | /! /,ヽ.、 /イ |_,、、ハ
l ! | ナレ´ ヽ\ル ヽ! リ
! | |/ ニ=- -=ニ K
l ゝ | xxx ' xx | }
. ! {r∧ r-ー--ァ ノ'
. ! `ー-r、 `ー---' イi |
. ! | | フ`、ー_‐ 〔 \ー、
l ! / \ ` .|、 | ヽ _/ ̄二フ >>540
l i / \_」|oV i ヽ /〈 つノ)
/|.ノ{ ⌒ヽ、 ヽ r‐‐!/ \ / ヽ´イー'
./ .| | 、 ヽ ニ二} ヽo ̄ヽ >'ヽ /
IT業界にいてもSE,PGが天職だと思える人は5%もいない。
9割以上は凡庸なプログラマ。残り5%弱がPGに向いてない人。
執筆者が1割も優秀ならまだいい方なのかもしれない。
まあ1割も適当に言っただけで根拠はないと思うけど。
んで10年後のMySQLとPostgresのシェアってどうなってると思う?
日本では拮抗、世界ではMySQLっていう今の状況(で、いいんだよね?)は
変わらないと思う?いろいろ覚えるの面倒だから一個でいいんだけど 覚えるの面倒だから一個でいいと言う人は一つもマスターできない気がする 例えば俺はポスグレメインなんだが、buffer, work_mem, fsync, commit_delay, check_point_segmentとかの
パフォーマンスに直結するパラメータをどれくらいに設定するのかとか、ORを使うくらいなら二個のSELECTをJOINした方が
早いとか(今は治ったけど)、VACUUM FULLしてもREINDEXしないとINDEXが小さくならないとか、
複数のDBについてそういう細かい特性の違いまで覚えるのは無駄だと思うんだ。
まあOracleも結構勉強したけど、フリーの奴は一個でいいかなって
例えば俺は醤油メインなんだが、塩分濃度、こく、うまみとかの
味に直結する要素をどれくらい把握するのかとか、手仕込みの醤油を使うなら味が安定しているキッコーマン使った方が
うまいとか(今は小さい蔵も品質安定してるけど)、無添加の醤油は劣化が早いから早めに使わないと味が変わるとか、
複数の調味料についてそういう細かい特性の違いまで覚えるのは無駄だと思うんだ。
まあ味噌も結構勉強したけど、フリーの奴は一個でいいかなって
っていう料理人いないだろ 醤油と味噌は用途が違うんだから両方知らないと駄目だろ。
みんなポスグレとMySQL両方とも各バージョンでどんな
変更があったとか把握してんの?
調味料で例えるなら、醤油を作ってる蔵Aと蔵Bがあって、蔵Aは大豆の刈り取りから
醤油になるまでのタイムラグがこれくらいだから何月頃に使うのがおいしいとか、
そういう細かいところを各蔵ごとに浅く広く覚えるより、一番おいしい蔵どころを一社見つけて
そこの醤油の特性を深いところまで覚えた方がいいってことだろ?
なにがおかしいのかわからん 味噌味の煮物か醤油味の煮物か
味噌汁かけんちん汁か
味噌ラーメンか醤油ラーメンか
の違いって事だろ 例えで混乱するのはこれくらいにして、みんなポスグレとMySQLで大方の設定パラメータまで暗記して使ってるの?
どっちも浅くしか使ってないんじゃないの? WindowsとMacとLinuxどれも使うみたいな程度の話だろ
何をキレてるんだ
そもそも他のDBの特徴もちゃんと把握してないとPostgreSQLを客に薦めることもできないだろ
これはPostgreSQLの方が優れてるんです!とかいっても、客にこないだのMySQLのバージョンアップで
そこはMySQLの方が良くなったよね?みたいに突っ込まれたらお前の仕事は
設定までたどり着かずにそこで終わりだ。 つまりお前はバージョンアップ毎に大体どんなとこが変わったか、
自分が関わるプロダクトについては抑えてる訳ね。それには敵わんわ。
DB以外の部分でいっぱいいっぱいだもの。
別に切れてないし、周りがどうなのか純粋に質問したかっただけ。ありがとう 末端部分の製造と設定の仕事しか請け負わない奴ならともかく、
システム全体請け負うフリーランスなら
プロダクトの選定からメンテナンスまで仕事じゃね普通? >>559
つーか導入時点で競合製品の比較やるために調査しないか普通。
逐次全部暗記してるわけじゃなくて、必要なら他のプロダクトについても調査するだけの話だぞ。
積極的にチェックするのはメジャーバージョンアップの時くらいでいいんだし。
俺はポスグレしか知らないし、他のプロダクトのこと学ぶのは意味がないとか言う奴に仕事が来るとは思えん。 わかってる人に質問。
今や、PostgreSQLがMySQLに勝る
ところは、ライセンスのわかりやすさ
だけなの?
MySQLは5.1以降の性能向上が
かなりいいらしいけど。
MySQLがPostgreSQLに勝る点
(1)オフィシャルサポートby Oracleがある
(2)DB毎、テーブル毎のレプリケーションができる
(3)サポートされているシステムやソフトが多い
以上。
パフォーマンスは使いかた次第。CPUコアに対するスケーラビリティはまだPostgresの勝ち。
ただしベンチマークだけで評価するのは素人。アプリ次第でパフォーマンスなんてどうにでもなる。
MySQLはトリガ、ストアドプロシージャがまだまだ弱い。check制約も未サポート。MyISAMは外部キーも未サポート。
ただしこれらを使うか使わないかはあなた次第。
メジャーバージョン間の互換性はPostgresが高い、というかMySQLはマイナーバージョンですら
互換性なくすから実際に運用してみるとどうしようもないことがわかる。
SQLレベルでもころころ仕様がかわるから、アプリケーションまで含めたシステムのバージョンアップに
とてつもないコストがかかる。
>>526
にあるように、レプリケーション用のスレーブを準備するのが大変。バックアップ/リストア機能がとてつもなく貧弱。
これが運用上最大の欠点。
ファイルシステムのスナップショット機能を利用するしかない。あらかじめ準備してなかったり、古い環境で作業させられたりするとアウト。
MySQLはバグも多い。バグフィックスの数が膨大。
もともと開発の稚拙さが目立っていたが最近ではAlterTableでクラッシュするバグが1年以上放置されたりとひどい。
スラドに「PostgreSQLやSQLiteがMySQLの代用になるとか、天と地が逆さになってもありえない。」
とか書いてるキチガイがいるな >>570
あんな基地外シッタカ放置だろ。言っていることの
全てに突っ込みどころがありまくり。 ./見てないけどSQLiteはともかくDRBMSなんてどれも同じだろ殆ど
運用方法や方言が違うだけで SQLiteは両者と比べてどの辺の位置づけになりますか?
http://gro.cc/across/ MySQL 5.5 になって、CPUスケーラビリティは PostgreSQL に追いつきましたか?
5.1 までは酷い性能だったみたいですが。 5.1+InnoDB Pluginでも実はまだ負けてたんだけど
5.5ならPostgreSQLとほぼ互角だと思われる MySQL vs PostgreSQL の時代は終わり。
Oracle vs PostgreSQL が適当。 MySQLのライセンスがよくわからんのでちょっと教えてください(´д`;)
(というか、みなさんどうやってるんだろう・・・)
【ケース1】
店主AはサイトBからMySQLを使ったフリーのショッピングカートシステム(PHP)をダウンロード。
店主Aはショッピングカートシステム(PHP)のソースをちょこっと変更して(文言とかデザインとか設定とか)
店主AはレンタルサーバC(MySQL利用可)にそのシステムをインストール。
店主Aはネットショップをオープン。
【ケース2】
店主Dは個人Eにネットショップの開発、設置を依頼。
個人EはMySQLを用いたショッピングカートシステム(PHP)を開発。
個人Eは店主Dが契約したレンタルサーバF(MySQL利用可)にそのシステムをインストール。
店主Dはネットショップをオープン。
これらのケースはよくあるパターンだと思うけど、誰がライセンス料を払う義務があるの?
・サイトBは自由にダウンロードできる状態でソースを公開してるのでGPLですかね。
・店主Aはソースを変更した上でソース非公開(※)で使ってるのでOEM?
※ショッピングサイトで「このサイトのシステムをダウンロード」があるのはおかしいw
・個人EがOEMとするとお小遣い稼ぎ程度のちょっとしたプログラム作成依頼でも全部OEM?
・MySQLをインストールした上で自由にユーザーに使わせてるレンタルサーバ屋は
ライセンス料とは無関係? MySQLというか、GPLについて
>・サイトBは自由にダウンロードできる状態でソースを公開してるのでGPLですかね。
GPLなWEBアプリの利用者は店主Aであって、サイトBの利用者ではない。
よって、ソースコードの公開は必要ない。
ただし、店主Aが変更したGPLアプリを、他人のWebサイトにセットアップするのであれば、
Webサイトの所有者に対し、GPLでソースコードを提供しなければならない。
>・個人EがOEMとするとお小遣い稼ぎ程度のちょっとしたプログラム作成依頼でも全部OEM?
GPLなWEBアプリを店主Dが利用するなら、当然個人Eは、そのソースコードを店主Dに提供しなければならない。
>・MySQLをインストールした上で自由にユーザーに使わせてるレンタルサーバ屋は
インストールしたMySQLのソースコードが公開されているWebサイトを紹介すれば、GPLに違反しているとは思われない。
よって、ライセンス料を支払う必要はない。 >サイトBは自由にダウンロードできる状態でソースを公開してるのでGPLですかね。
サイトBが提供している、ショッピングカートシステム(PHP)がGPLかどうかは、
提供者に聞かないと分からない。
ダウンロードできるなら、利用ライセンスがどこかに書いてあると思うが… MySQLで、ライセンス料を払わなければいけないのは、
MySQLで動く自社著作物のソフトウェアを、
(独占的ライセンスで利用権を販売するなど)非GPLで他社に提供する場合。
GPLにおいて、レンタルサーバで動かすアプリケーションの利用者とは借り手のこと。サーバにアクセスする人は対象外。
GPLのソフトウェアのソースコードは、利用者にのみ提供すればそれでいい。
他社に請負で作ってもらった、著作権が自社に帰属する自社利用のWebアプリケーションは、My SQLのライセンス料を払わなくていいし、
GPLアプリケーションを改良し、自社で利用するだけであれば、他社に公開する必要もない。 >>583 >>584
レスありがとうございます。
ちょっと勘違いしてました。GPLとするときにソースを公開しないといけない相手は
「(WEB利用者も含む)世の中全体」ではなくて
「プログラムの著作物の複製物を所持している者」なのですね。
ケース2の場合だと店主Dに対してソースを公開するならGPLとなり
個人Eはライセンス料を払う必要がないのですね。
(ただし、店主Dには頒布権が発生しますから、店主Dによって個人Eが作成した
プログラムが世の中にばらまかれる可能性はありますが、そこは信頼関係でカバー?w)
この記事を読んで混乱したのですが、これは間違ってるということでいいんでしょうか?
http://www.atmarkit.co.jp/flinux/rensai/mysql01/mysql01.html#c
>MySQLをインストールしたサーバをASPなどの商用に利用する場合にはライセンス料が発生します
レンタルサーバ会社にもライセンス料が発生するようにも読めますが・・・
レンタルサーバ以外の一般的な有料ASPサービス(ショッピングカート、予約システムなど)の場合であっても
そもそも第三者にプログラムを頒布しませんから関係ないですよね?
>開発したアプリケーションのソースコードを広く一般に公開すれば課金はまぬがれますが
「広く一般に」ではなく「販売先(頒布先)に」ですよね?
>>585
わかりやすい解説ありがとうございます!
独占的ライセンスが必要な時以外はGPLでOKなんですね〜
しかし、A社が納品したプログラムをB社が完全に自由にできるっていうのもなんだかなぁ・・・
(丸ごとコピーして売ってもいいし、自社HPから自由にDLさせても良いということになるよね) >(ただし、店主Dには頒布権が発生しますから、店主Dによって個人Eが作成した
> プログラムが世の中にばらまかれる可能性はありますが、そこは信頼関係でカバー?w)
>(丸ごとコピーして売ってもいいし、自社HPから自由にDLさせても良いということになるよね)
GPLの理念は、利用者のソフトウェアの自由を保障することだから、これを禁止してはいけない
これはあなたが他のGPLソフトウェアを利用する時の権利にもなる
>MySQLをインストールしたサーバをASPなどの商用に利用する場合にはライセンス料が発生します
http://www.mysql.com/about/legal/licensing/oem/
http://www.softagency.co.jp/products/mysql/license/
などを読む限り、頒布しないかぎりライセンス料は発生しないと思われる(責任は持たない)
さらに気になるなら、上記リンク先から、問い合わせることもできる。
>しかし、A社が納品したプログラムをB社が完全に自由にできるっていうのもなんだかなぁ・・・
日本で一般的なソフトウェア開発は、開発者の労働役務の提供による請負契約で、
著作物の権利は、すべて納品先に帰属する。
そうでなく、著作物のソフトウェア製品の利用ライセンスを販売する、製品販売契約の場合、あなたは当然GPLやその他のライセンスを適用できる。
ただし、GPL以外でMy SQLを利用した製品を販売する場合、上記の通りMy SQLにライセンス料を払わなくてはならない。 >>588
どう読んでも、そんな結論にならないだろ。
MYSQLを使用したソフトウェアを引き渡す場合、(形態を問わず)
GPL(ソフトウェアのソースを公開)にして下さい。
GPLにしない場合、コマーシャルライセンスを買ってください。
だろ。
「頒布しないかぎりライセンス料は発生しない」
ってどこを読んだんだよ。 >>591
MySQLは、自分自身もGPLだけど、使うソフト(WEBサイト)もGPLであることを求めている。
GPLの規約自体は、この際あまり関係ない。
ものすごくわかりにくいけど、ここの2番目の章。
http://www-jp.mysql.com/about/legal/licensing/faq.html
要約すると、
「MySQLはオープンソースを推進しているので、オープンソースのソフトからMySQLを使用しても金を取りません。」
1番目の章でも、良く読めば、
「MySQL 製品を使用」する場合、使用するアプリケーション(WEBサイト含む)はGPLにして下さい。
そうしない場合、商用ライセンスを購入してください。 」
ってあいまいに書いている。 >>590
これは流石に酷い・・。中国並みのライセンス意識だわ・・。
MySQLというソフトを使用するなら、日本だと、MySQLの販売代理店に金を払う。
「mysql 購入」でググれば、代理店いっぱい出てくる。
頒布しなくても、windowsを使用する場合、windowsのライセンスは買うだろ。
まあ、お前は海賊版使ってるのかもしれないけどさ。 >>591
使うソフト(WEBサイト)を自社のみで使う(NDAなどで委託先に開発させたものを含む)場合には、
利用者(自社)がソースコードなどをGPLに基づいて利用できる状態にあればよいわけで
GPLを尊守しているかぎり、第三者にバイナリを提供していないにもかかわらずソースコードを開示する義務はなくて、
従って、バイナリやソースコードを第三者に頒布しなくとも(GPLを尊守しているかぎり)、
商用ライセンスを購入する必要はないと読める >>593
MySQLを自分で使用するだけなら金を払う必要ないよ。
RHELやCentOSにMySQLの価格は含まれていないでしょう。
もし金を払う必要があったら本屋で売ってる
CentOSのDVD-ROM付きガイド本が20万円以上することになる
買うのはサポートが欲しいときと、GPLを外したいとき >>595
ぽかーん
CentOSにMySQL入ってないだろ。
MySQLのダウンロードは無料。
使用するなら、使用するソフトをGPLで公開する。
じゃなきゃ、金を払う。
MySQLは営利企業が開発して、販売してるソフトだぞ。
ただ、使うソフトをGPLで公開すれば、無料で使えますってだけ。 >>597
入ってるのか。
いつも最小インストールだから、知らなかった。 ■ このスレッドは過去ログ倉庫に格納されています