PHP + PostgreSQL
■ このスレッドは過去ログ倉庫に格納されています
0001りさあ
NGNG0002名無しさん＠お腹いっぱい。
NGNG石井君のページにでも行ってくれ。
0003名無しさん＠お腹いっぱい。
NGNG7.1からOUTER JOINもサポートされるし。
初心者、金は無いがスキルを磨きたい物にはうってつけだ。
0004いしい
NGNG0005名無しさん＠お腹いっぱい。
NGNG0006名無しさん＠お腹いっぱい。
NGNGやっぱマイでしょ、マイ。
0007名無しさん＠お腹いっぱい。
NGNG>Apache+PHP+PostgreSQLは最強の解といえるでしょう。
最強ﾀﾞｯﾃ...
あイタタタタタタ｡｡｡｡
0008いC
NGNG0009名無しさん＠お腹いっぱい。
NGNG0010名無しさん＠お腹いっぱい。
NGNG0011いC
NGNG0012名無しさん＠お腹いっぱい。
NGNG0013名無しさん＠お腹いっぱい。
NGNGoracleと同等の性能出せるんなら考えてもいいよ。
0014名無しさん＠お腹いっぱい。
NGNG要は適材適所。
別にPostgeSQLがOracleと同等の性能を出す必要は無し。
コンサル受ける必要は全く無いが（ｗ
0015名無しさん＠お腹いっぱい。
NGNGけどモノは使いようでメンテ必須という名目で保守契約結ぶとか
バックアップきっちり取れるとか悪いことばかりじゃないし。
取りあえずｄｂに金出さない貧乏クライアントは逝ってよし。
0016名無しさん＠お腹いっぱい。
NGNG0017名無しさん＠お腹いっぱい。
NGNGここは、Oracle最高っつー奴らばかりなのか？
00181
NGNGやっぱ低レベルだわここの人達。。。
0020名無しさん＠お腹いっぱい。
NGNG自己のアイデンティティーを確立しようとするような奴らが多いからさ、
そのへん割り引いてくれよ。
0021名無しさん＠お腹いっぱい。
NGNG7もだが4も理由無しだな。どっちもどっち。
0022電動ナナシ
NGNGOracle vs PostgreSQL
PostgreSQL vs MySQL
みたいに実装系の比較の話になっちゃうの？
ほかに話すこといろいろありそうじゃん。
データベース板とか作ってもらったら？
隔離板になっちゃうかもしれないけどね。
0023電動ナナシ
NGNG・ある実装系が向いている仕様にはどんなものがあるか？
・ある実装系が向いていない仕様にはどんなものがあるか？
って観点で話さないと全然意味ないと思うよ。どんな実装系にだって設計思想があって、
それによって得意・不得意が出てくるんだから。
例えばデータサイズで言えば、
・単一ファイルシステムのサイズの限界があるか？
yes: PostgreSQL, MySQL
no: Oracle
となる以上、ファイルシステムの上限 (例えば 4GB) を超えるデータを MySQL 等で
扱うのはおかしいって話だよね。
逆に、オブジェクト指向言語実装系において、あるオブジェクトを永続化させるのに
便利なデータベースは？って問題なら
Yes!!: PostgreSQL (テーブル定義に継承が利用できるので、クラス定義と同じ構成の
テーブルを作成できる）
Yes: Enterprise Edition なら、オブジェクト型 (View) の定義ができる
No: その他（自分でインピーダンス不整合を解消する必要がある）
という風になるでしょ？だからこういった言語処理系を前提にしたならば、PostgreSQL か
Oracle かって話しになることが多いだろうね。
こういう前提条件無視してまともな議論になるはずがないんだと思うけど？
0024電動ナナシ
NGNGつまり、どのデータベースの実装系かってことを意識しないですむようにコーディング
するのが普通になってきているわけだよね。
何でこんなことをするかって言うと、
・開発時のデータベースと運用時のデータベースが違う（高くて買えない場合等）
・データベースに求められる仕様が変更される（例えば性能から安定性へ変わった場合）
という場合がありうるので、移植の手間を省くためにそういうことをするわけだ。さらに
抽象化は、そのためのクラスを通じて行うけど、これを大勢が何度も使うことによって
クラスの品質と使い勝手が向上して、より再利用しやすくなるって副作用もあるよね。
そうだとすると、そんな PostgreSQL はどうよ？とか MySQL はどうよ？的な質問は
意義を失ってくると思うんだが、どうよ？
# だいたい大半の人間は標準 SQL の範囲内でしか SQL 使ってないでしょ？関数とかは
実装依存になるけど、じゃあ CASE とか /*++ とか使ってる人ってどのくらい
いるんだろ？
まあそのうちゆり戻しがくるだろうけどさ、それは性能が最優先課題になる場合くらいしか
出てこないだろうね。
0025電動ナナシ
NGNG例をあげるなら型キャストとかだったな・・。
鬱出し脳。
0026名無しさん＠お腹いっぱい。
NGNG＞PostgreSQL vs MySQL
頭の中のこんな図式持ってる奴はマカー死ねとかFreeBSD氏ねとか言ってる
のと同次元だ。
00271
NGNGなんか人来なそうだな（わ
やっぱりORACLEはpostgresよりはえーぜ！
とか
Myが最高！！
とかここみたく言う人ばかりだろうね
0028名無しさん＠どっと混む
NGNG0029名無しさん＠お腹いっぱい。
NGNG厨房はお前だ。
0030名無し
NGNGどうしたら、そこまでのめり込めるのでしょうか。
冒頭で書いたようなバカっぽいことでウダウダ言ってる割に、技術的には素人から見て凄そうなので
前から不思議に思ってました。UNIX板のスレなど。
煽りじゃないです。
0031電動ナナシ
NGNG作っている人間が熱くなるならわかるけど、作っている本人よりも取り巻きの方が
熱かったりするからねえ。
確かにそこまでのめりこんで見えるものがあるのも事実だと思うけど・・。
# でも最近のメーリングリストの内容の水準の低下を見るとそうでもないか？
どこでもインストールネタばっかりだし。
00321
NGNG一応Oracle、SQLSerer、My、Postgersとこの4つで開発やってるんですが、
まだドキュメントとかPostgresは少ないからチューニングの仕方がわからないんですよね。
SQLの書き方によるパフォーマンスっていろいろ試してわかってきたんですけど。
Oracleほどインデックスの効果がでないとか。。
サーバ側でいろいろチューニング試した方とかいらっしゃいますかね？？
Oracleゴールドなんか持ってっても全然意味ないな。。。。
これじゃ
00331
NGNG私の作ってるサイト（携帯コンテンツ）はかなりのアクセスがあるんで
トランザクションの数が尋常じゃないもんで
それに耐えうるような方法とかご存知でしたら知りたい・・
0034いC
NGNG0035名無しさん＠お腹いっぱい。
NGNGhttp://www.microsoft.com/Japan/SQL/
0036>35
NGNGバカチョンって感じかな。。
メンテとかはしやすい
チューニングは意味ない
0037電動ナナシ
NGNGからチューニングは一苦労だよね。
http://www.linux.or.jp/JF/JFdocs/PostgreSQL-FAQ.html の
3.7, 4.9, 4.10, 4.23 あたりは読んだ？
あとはこの辺かな。
http://www.itboost.co.jp/postgresql/pgsql_tips.php3
あと Vacuum かけないと Index は効果半減。Vacuum と Index の関係については
以下が参考になるかも？
http://www.geocrawler.com/archives/3/6/2000/3/50/3402101/
以上に書いてない事柄で、自分が知っているのはこれくらい。
1 もこれくらいは知っているだろうけど。
・PostgreSQL は遺伝的アルゴリズムを用いてアクセスパスを決定しているが、
非常に複雑なクエリーの場合、計算量が増えすぎてしまって、そこで余計な
時間をつぶすことがある。
$PGDATA/pg_geqo (pg_geqo.sample をコピー) の Generations をぐっと
減らすと、効率は悪くなるが計算時間も減るので、割と単純なクエリーの
場合には効果が大きい。
・Join することがないテーブル群がある場合、別々のデータベースに格納し、
かつそれぞれのデータベースを別のディスク I/O に置く。詳細は Admin Guide の
Chapter 10 "Disk Management" を参照。
先のリンクにあるようにテーブルを作って別のディスク上に移動し ln -s
するのでもよし。
・PostgreSQL のセッションコンテキストの変数を操作することで、アクセス
パスを手動で最適化することができる（これは今回はじめて知った・・）。
詳細は Users Guide の 17. Understanding Performace と 19. の sql-set を
参照。
# 探せば結構出てくるじゃん。
0038電動ナナシ
NGNG> 割と単純なクエリーの 場合には効果が大きい
割と複雑な・・・の間違い。
あと、テーブル構成とかはきちんと設計できてるんだよね？
join 操作はコストが大きいから、むやみやたらにテーブルを分けるのはまずい、
場合によっては非正規化も検討するとよいってよく言われる。ただしデータの
整合性を維持するのに Trigger 使うくらいなら join した方が 100 倍いい。
あと index は本当に効果的な場合（つまり WHERE で条件として指定される場合）に
限定して使わないと、レコードを変更・追加するときのコストが大きくなる。
さらにファイル断片化とか起きないように、非常に大きなテーブルは専用の区画を
用意するとか、ときどき export & drop table & import してクリーニング
するとか・・・。
# まあこの辺は PostgreSQL に限らず、常識的な内容ばかりで・・。
0039電動ナナシ
NGNGということで話題を変更。
PHP スクリプトのデータベースアクセスにも改善の余地はないの？
細かくアクセスするよりまとめてレコード取得したほうが速いってのは
いいだろうけど、コネクションを永続化するとか、日付計算ごときでデータベースを
呼ばないとかはしているよね。
それでもダメなら Zend Optimizer 試してみて、それでもダメなら Zend
Cache 使ってみれば（試用可能）？
0040名無しさん＠お腹いっぱい。
NGNGあんたすごいね
■ このスレッドは過去ログ倉庫に格納されています