のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,654,347人
昨日:no data人
今日:
最近の注目
人気の最安値情報

元スレPHP + PostgreSQL

php覧 / PC版 /
スレッド評価: スレッド評価について
みんなの評価 :
タグ : - タグè¿1⁄2åŠ + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

1 :

語りません?

2 :

語ることがない。
石井君のページにでも行ってくれ。

5 = :

ひょっとして、結論が出てしまったのでしょうか?

6 :

ポストグレは遅いよ。ていうか海外ではぜんぜん人気ないし。
やっぱマイでしょ、マイ。

8 :

君たち、僕の著書をよんでないようだね(藁

9 :

痛ずぎ....

11 :

みなさん、こんなとこで勉強しないで、僕がコンサルしてあげるよ。タダとは言わないからさ。

13 :

>>11
oracleと同等の性能出せるんなら考えてもいいよ。

15 :

vacuum が無くなればそれなりなんだけどな。>pgSQL
けどモノは使いようでメンテ必須という名目で保守契約結ぶとか
バックアップきっちり取れるとか悪いことばかりじゃないし。

取りあえずdbに金出さない貧乏クライアントは逝ってよし。

16 :

遊ぶだけなのに何百万も払いたくない>Oracle

17 = :

ほかの板だと、Oracle劇遅っつーのが、一般的見解なんだが、
ここは、Oracle最高っつー奴らばかりなのか?

19 = :

>>18
「語れ」しかいえないお前が一番低レベル。
「語れ」だけで高レベルな情報を得ようというのは虫が良すぎ。

20 = :

まぁ、ここの人たちってさ、>>7みたいに、理由もなく何かを貶めて、
自己のアイデンティティーを確立しようとするような奴らが多いからさ、
そのへん割り引いてくれよ。

21 = :

>>20
7もだが4も理由無しだな。どっちもどっち。

22 :

でもさー、何でデータベースの話になるとすぐ
Oracle vs PostgreSQL
PostgreSQL vs MySQL
みたいに実装系の比較の話になっちゃうの?
ほかに話すこといろいろありそうじゃん。

データベース板とか作ってもらったら?
隔離板になっちゃうかもしれないけどね。

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 万回以上にもなるけど、何か壊れたことはない。ディスク障害とか別の原因が
あったんじゃないの?


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
スレッド評価: スレッド評価について
みんなの評価 :
タグ : - タグè¿1⁄2åŠ + 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

類似してるかもしれないスレッド


トップメニューへ / →のくす牧場書庫について