元スレPHP + PostgreSQL
php覧 / PC版 / みんなの評価 : ○
1 :
語りません？
2 :
語ることがない。
石井君のページにでも行ってくれ。
5 = :
ひょっとして、結論が出てしまったのでしょうか？
6 :
ポストグレは遅いよ。ていうか海外ではぜんぜん人気ないし。
やっぱマイでしょ、マイ。
8 :
君たち、僕の著書をよんでないようだね(藁
9 :
痛ずぎ....
11 :
みなさん、こんなとこで勉強しないで、僕がコンサルしてあげるよ。タダとは言わないからさ。
13 :
>>11
oracleと同等の性能出せるんなら考えてもいいよ。
15 :
vacuum が無くなればそれなりなんだけどな。>pgSQL
けどモノは使いようでメンテ必須という名目で保守契約結ぶとか
バックアップきっちり取れるとか悪いことばかりじゃないし。
取りあえずｄｂに金出さない貧乏クライアントは逝ってよし。
16 :
遊ぶだけなのに何百万も払いたくない＞Oracle
17 = :
ほかの板だと、Oracle劇遅っつーのが、一般的見解なんだが、
ここは、Oracle最高っつー奴らばかりなのか？
19 = :
>>18
「語れ」しかいえないお前が一番低レベル。
「語れ」だけで高レベルな情報を得ようというのは虫が良すぎ。
20 = :
まぁ、ここの人たちってさ、>>7みたいに、理由もなく何かを貶めて、
自己のアイデンティティーを確立しようとするような奴らが多いからさ、
そのへん割り引いてくれよ。
21 = :
>>20
7もだが4も理由無しだな。どっちもどっち。
22 :
でもさー、何でデータベースの話になるとすぐ
Oracle vs PostgreSQL
PostgreSQL vs MySQL
みたいに実装系の比較の話になっちゃうの？
ほかに話すこといろいろありそうじゃん。
データベース板とか作ってもらったら？
隔離板になっちゃうかもしれないけどね。
23 = 22 :
でさー、こういう実装系の話をするときって、
・ある実装系が向いている仕様にはどんなものがあるか？
・ある実装系が向いていない仕様にはどんなものがあるか？
って観点で話さないと全然意味ないと思うよ。どんな実装系にだって設計思想があって、
それによって得意・不得意が出てくるんだから。
例えばデータサイズで言えば、
・単一ファイルシステムのサイズの限界があるか？
yes: PostgreSQL, MySQL
no: Oracle
となる以上、ファイルシステムの上限 (例えば 4GB) を超えるデータを MySQL 等で
扱うのはおかしいって話だよね。
逆に、オブジェクト指向言語実装系において、あるオブジェクトを永続化させるのに
便利なデータベースは？って問題なら
Yes!!: PostgreSQL (テーブル定義に継承が利用できるので、クラス定義と同じ構成の
テーブルを作成できる）
Yes: Enterprise Edition なら、オブジェクト型 (View) の定義ができる
No: その他（自分でインピーダンス不整合を解消する必要がある）
という風になるでしょ？だからこういった言語処理系を前提にしたならば、PostgreSQL か
Oracle かって話しになることが多いだろうね。
こういう前提条件無視してまともな議論になるはずがないんだと思うけど？
24 = 22 :
あとさー、最近のトレンドは「データベース抽象化」でしょ？
つまり、どのデータベースの実装系かってことを意識しないですむようにコーディング
するのが普通になってきているわけだよね。
何でこんなことをするかって言うと、
・開発時のデータベースと運用時のデータベースが違う（高くて買えない場合等）
・データベースに求められる仕様が変更される（例えば性能から安定性へ変わった場合）
という場合がありうるので、移植の手間を省くためにそういうことをするわけだ。さらに
抽象化は、そのためのクラスを通じて行うけど、これを大勢が何度も使うことによって
クラスの品質と使い勝手が向上して、より再利用しやすくなるって副作用もあるよね。
そうだとすると、そんな PostgreSQL はどうよ？とか MySQL はどうよ？的な質問は
意義を失ってくると思うんだが、どうよ？
# だいたい大半の人間は標準 SQL の範囲内でしか SQL 使ってないでしょ？関数とかは
実装依存になるけど、じゃあ CASE とか /*++ とか使ってる人ってどのくらい
いるんだろ？
まあそのうちゆり戻しがくるだろうけどさ、それは性能が最優先課題になる場合くらいしか
出てこないだろうね。
25 = :
あーうー、いかん。case も標準 SQL だ。
例をあげるなら型キャストとかだったな・・。
鬱出し脳。
28 = :
お前も人のこと言えんのかこのポストグレス厨房
29 = :
これ以上荒らすな、バカヤロ。
厨房はお前だ。
30 = :
PostgreSQL だ MySQL だ Oracle だ とかって、そこまで熱くなれる人たちって、ある意味羨ましいです。
どうしたら、そこまでのめり込めるのでしょうか。
冒頭で書いたようなバカっぽいことでウダウダ言ってる割に、技術的には素人から見て凄そうなので
前から不思議に思ってました。UNIX板のスレなど。
煽りじゃないです。
31 = :
宗教だねえ、ここまでくると。
作っている人間が熱くなるならわかるけど、作っている本人よりも取り巻きの方が
熱かったりするからねえ。
確かにそこまでのめりこんで見えるものがあるのも事実だと思うけど・・。
# でも最近のメーリングリストの内容の水準の低下を見るとそうでもないか？
どこでもインストールネタばっかりだし。
34 :
知ってるけど教えてあげない。コンサルする？
38 = :
>>37
> 割と単純なクエリーの 場合には効果が大きい
割と複雑な・・・の間違い。
あと、テーブル構成とかはきちんと設計できてるんだよね？
join 操作はコストが大きいから、むやみやたらにテーブルを分けるのはまずい、
場合によっては非正規化も検討するとよいってよく言われる。ただしデータの
整合性を維持するのに Trigger 使うくらいなら join した方が 100 倍いい。
あと index は本当に効果的な場合（つまり WHERE で条件として指定される場合）に
限定して使わないと、レコードを変更・追加するときのコストが大きくなる。
さらにファイル断片化とか起きないように、非常に大きなテーブルは専用の区画を
用意するとか、ときどき export & drop table & import してクリーニング
するとか・・・。
# まあこの辺は PostgreSQL に限らず、常識的な内容ばかりで・・。
40 = :
>>電動ナナシ
あんたすごいね
41 :
>>電動ナナシ
超参考になりました
やっぱちゃんと開発前に時間とっていろいろ考えないとだめですよね。。
でも開発の時間のけつは決まってるし、開発と運用両刀じゃすでに終わってる感じ
インデックス張ってんのにやたらおせーと思ったらそうゆうことでしたか。。。
バキュームね
43 = :
>>40
全然すごくない。厨房レベルだよ。
>>41
RDBMS はテーブル設計が超重要だからね、事前に時間をとってきちんと設計しないと結構
悲惨なことになるよ。特に忙しいサイトだとね。データ見せられてすぐに第三正規化できる
程度に正規化には習熟しておこう。
『Oracle パフォーマンスチューニング』読んでみるといいよ。Oracle と書いてあるけど、
ベースになる思考や知識は共通。だって RDBMS じゃん。メモリアクセスやディスク
アクセスのパターンがそんなに劇的に変わるはずがない。
Vacuum は index から使われないエントリを削るので、頻繁に削除・変更が起きるなら
必須だね。Rebuild はしてくれないような話も聞くが・・・。explan 使って index が
使われているか確認してみたら？
>>42
Vacuum で何か壊れたって経験はないなあ。自分の面倒見ている範囲では、もう vacuum
回数は 1 万回以上にもなるけど、何か壊れたことはない。ディスク障害とか別の原因が
あったんじゃないの？
みんなの評価 : ○
php一覧へ類似してるかもしれないスレッド
- PHP PHPって (73) - [24%] - 2016/1/21 13:46
- Mac OS X + PHP + MySQL (199) - [21%] - 2022/3/13 12:00
トップメニューへ / →のくす牧場書庫について