PHP + PostgreSQL

1 ： 2001/02/26(月) 〜 最終レス ：12/01/02

語りません？

2 ：

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

3 ：

フリーの割りに高性能。＜pgsql
7.1からOUTER JOINもサポートされるし。
初心者、金は無いがスキルを磨きたい物にはうってつけだ。

4 ：

Apache+PHP+PostgreSQLは最強の解といえるでしょう。

5 ：

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

6 ：

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

7 ：

>>4
>Apache+PHP+PostgreSQLは最強の解といえるでしょう。
最強ﾀﾞｯﾃ...
あイタタタタタタ｡｡｡｡

8 ：

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

9 ：

痛ずぎ....

10 ：

8K制限なくなった…

11 ：

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

12 ：

4＝馬鹿

13 ：

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

14 ：

OracleだろーがPostgreSQLだろーがMySQLだろーがはたまたInterBaseだろーが
要は適材適所。
別にPostgeSQLがOracleと同等の性能を出す必要は無し。
コンサル受ける必要は全く無いが（ｗ

15 ：

vacuum が無くなればそれなりなんだけどな。>pgSQL
けどモノは使いようでメンテ必須という名目で保守契約結ぶとか
バックアップきっちり取れるとか悪いことばかりじゃないし。
取りあえずｄｂに金出さない貧乏クライアントは逝ってよし。

16 ：

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

17 ：

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

18 ：

ORACLE最高とかPostgres最強とかそんなことどーでもいいんだけどさ・・
やっぱ低レベルだわここの人達。。。

19 ：

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

20 ：

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

21 ：

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

22 ：

でもさー、何でデータベースの話になるとすぐ
Oracle vs PostgreSQL
PostgreSQL vs MySQL
みたいに実装系の比較の話になっちゃうの？
ほかに話すこといろいろありそうじゃん。
データベース板とか作ってもらったら？
隔離板になっちゃうかもしれないけどね。

23 ：

でさー、こういう実装系の話をするときって、
・ある実装系が向いている仕様にはどんなものがあるか？
・ある実装系が向いていない仕様にはどんなものがあるか？
って観点で話さないと全然意味ないと思うよ。どんな実装系にだって設計思想があって、
それによって得意・不得意が出てくるんだから。
例えばデータサイズで言えば、
・単一ファイルシステムのサイズの限界があるか？
　yes: PostgreSQL, MySQL
　no: Oracle
となる以上、ファイルシステムの上限 (例えば 4GB) を超えるデータを MySQL 等で
扱うのはおかしいって話だよね。
逆に、オブジェクト指向言語実装系において、あるオブジェクトを永続化させるのに
便利なデータベースは？って問題なら
Yes!!: PostgreSQL (テーブル定義に継承が利用できるので、クラス定義と同じ構成の
　　　　テーブルを作成できる）
Yes: Enterprise Edition なら、オブジェクト型 (View) の定義ができる
No: その他（自分でインピーダンス不整合を解消する必要がある）
という風になるでしょ？だからこういった言語処理系を前提にしたならば、PostgreSQL か
Oracle かって話しになることが多いだろうね。
こういう前提条件無視してまともな議論になるはずがないんだと思うけど？

24 ：

あとさー、最近のトレンドは「データベース抽象化」でしょ？
つまり、どのデータベースの実装系かってことを意識しないですむようにコーディング
するのが普通になってきているわけだよね。
何でこんなことをするかって言うと、
・開発時のデータベースと運用時のデータベースが違う（高くて買えない場合等）
・データベースに求められる仕様が変更される（例えば性能から安定性へ変わった場合）
という場合がありうるので、移植の手間を省くためにそういうことをするわけだ。さらに
抽象化は、そのためのクラスを通じて行うけど、これを大勢が何度も使うことによって
クラスの品質と使い勝手が向上して、より再利用しやすくなるって副作用もあるよね。
そうだとすると、そんな PostgreSQL はどうよ？とか MySQL はどうよ？的な質問は
意義を失ってくると思うんだが、どうよ？
# だいたい大半の人間は標準 SQL の範囲内でしか SQL 使ってないでしょ？関数とかは
　実装依存になるけど、じゃあ CASE とか /*++ とか使ってる人ってどのくらい
　いるんだろ？
まあそのうちゆり戻しがくるだろうけどさ、それは性能が最優先課題になる場合くらいしか
出てこないだろうね。

25 ：

あーうー、いかん。case も標準 SQL だ。
例をあげるなら型キャストとかだったな・・。
鬱出し脳。

26 ：

＞Oracle vs PostgreSQL
＞PostgreSQL vs MySQL
頭の中のこんな図式持ってる奴はマカーとかFreeBSDとか言ってる
のと同次元だ。

27 ：

データベース版依頼だそうかな？
なんか人来なそうだな（わ
やっぱりORACLEはpostgresよりはえーぜ！
とか
Myが最高！！
とかここみたく言う人ばかりだろうね

28 ：

お前も人のこと言えんのかこのポストグレス厨房

29 ：

これ以上荒らすな、バカヤロ。
厨房はお前だ。

30 ：

PostgreSQL だ MySQL だ Oracle だ とかって、そこまで熱くなれる人たちって、ある意味羨ましいです。
どうしたら、そこまでのめり込めるのでしょうか。
冒頭で書いたようなバカっぽいことでウダウダ言ってる割に、技術的には素人から見て凄そうなので
前から不思議に思ってました。UNIX板のスレなど。
煽りじゃないです。

31 ：

宗教だねえ、ここまでくると。
作っている人間が熱くなるならわかるけど、作っている本人よりも取り巻きの方が
熱かったりするからねえ。
確かにそこまでのめりこんで見えるものがあるのも事実だと思うけど・・。
# でも最近のメーリングリストの内容の水準の低下を見るとそうでもないか？
　どこでもインストールネタばっかりだし。

32 ：

ども厨房26歳の1です。
一応Oracle、SQLSerer、My、Postgersとこの4つで開発やってるんですが、
まだドキュメントとかPostgresは少ないからチューニングの仕方がわからないんですよね。
SQLの書き方によるパフォーマンスっていろいろ試してわかってきたんですけど。
Oracleほどインデックスの効果がでないとか。。
サーバ側でいろいろチューニング試した方とかいらっしゃいますかね？？
Oracleゴールドなんか持ってっても全然意味ないな。。。。
これじゃ

33 ：

あ
私の作ってるサイト（携帯コンテンツ）はかなりのアクセスがあるんで
トランザクションの数が尋常じゃないもんで
それに耐えうるような方法とかご存知でしたら知りたい・・

34 ：

知ってるけど教えてあげない。コンサルする？

35 ：

SQL Serverはどうよ
http://www.microsoft.com/Japan/SQL/

36 ：

なんでPHP版に？
バカチョンって感じかな。。
メンテとかはしやすい
チューニングは意味ない

37 ：

PostgreSQL って Oracle ほどシステム統計取れない（というか全然取れない）
からチューニングは一苦労だよね。
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 を
　参照。
# 探せば結構出てくるじゃん。

38 ：

>>37
> 割と単純なクエリーの 場合には効果が大きい
割と複雑な・・・の間違い。
あと、テーブル構成とかはきちんと設計できてるんだよね？
join 操作はコストが大きいから、むやみやたらにテーブルを分けるのはまずい、
場合によっては非正規化も検討するとよいってよく言われる。ただしデータの
整合性を維持するのに Trigger 使うくらいなら join した方が 100 倍いい。
あと index は本当に効果的な場合（つまり WHERE で条件として指定される場合）に
限定して使わないと、レコードを変更・追加するときのコストが大きくなる。
さらにファイル断片化とか起きないように、非常に大きなテーブルは専用の区画を
用意するとか、ときどき export & drop table & import してクリーニング
するとか・・・。
# まあこの辺は PostgreSQL に限らず、常識的な内容ばかりで・・。

39 ：

つか、何が悲しくて PHP 板に PostgreSQL の話を書かないといけないんだ！？
ということで話題を変更。
PHP スクリプトのデータベースアクセスにも改善の余地はないの？
細かくアクセスするよりまとめてレコード取得したほうが速いってのは
いいだろうけど、コネクションを永続化するとか、日付計算ごときでデータベースを
呼ばないとかはしているよね。
それでもダメなら Zend Optimizer 試してみて、それでもダメなら Zend
Cache 使ってみれば（試用可能）？

40 ：

>>電動ナナシ
あんたすごいね

41 ：

>>電動ナナシ
超参考になりました
やっぱちゃんと開発前に時間とっていろいろ考えないとだめですよね。。
でも開発の時間のけつは決まってるし、開発と運用両刀じゃすでに終わってる感じ
インデックス張ってんのにやたらおせーと思ったらそうゆうことでしたか。。。
バキュームね

42 ：

bakyu-mu kowai mukashi view ga kowaretayo

43 ：

>>40
全然すごくない。厨房レベルだよ。
>>41
RDBMS はテーブル設計が超重要だからね、事前に時間をとってきちんと設計しないと結構
悲惨なことになるよ。特に忙しいサイトだとね。データ見せられてすぐに第三正規化できる
程度に正規化には習熟しておこう。
『Oracle パフォーマンスチューニング』読んでみるといいよ。Oracle と書いてあるけど、
ベースになる思考や知識は共通。だって RDBMS じゃん。メモリアクセスやディスク
アクセスのパターンがそんなに劇的に変わるはずがない。
Vacuum は index から使われないエントリを削るので、頻繁に削除・変更が起きるなら
必須だね。Rebuild はしてくれないような話も聞くが・・・。explan 使って index が
使われているか確認してみたら？
>>42
Vacuum で何か壊れたって経験はないなあ。自分の面倒見ている範囲では、もう vacuum
回数は 1 万回以上にもなるけど、何か壊れたことはない。ディスク障害とか別の原因が
あったんじゃないの？

44 ：

Vacuumしなきゃいけない構造はそのうち変えるつもりだって
本家のMLでいってたな＜Postgres
PHP+PostgreSQLってやはり最初はとっつきだよなやすい組合せだよな

45 ：

電動ナナシ＝いしい
？

46 ：

>45
うそ。１４１氏なら、文書の最後は。じゃなくて"."

47 ：

今日初めてPostgreSQL+PHP3の組合せに取り組みました。
早速本などを参考にデータベースよりデータを取り出してみようと思ったのですが、
いきなりエラーです。
エラーは
"Unable to connect to PostgreSQL server. FATAL 1: SetUserId :
user' nobody' is not in 'pg_shadow' in /usr/local/apache/...(略)... on
line 10"
みたいに出て来ました。
これはapacheのconfiguファイルで、接続先を設定しなければならないエラーなのでしょ
うか?

48 ：

nobody に　テーブルに対するアクセス権限を認めてあげましょう。

49 ：

>>48
これは/usr/local/pgsql/data/pg_hba.confのlocalとhostで編集でしょうか。
今このファイルを見ましたら、デフォルト設定になっていました。
一応どちらもallになっており、更にはこのファイルもreadonlyモードにしてみました。
しかし、やっぱり結果は同じでした・・・
本当に右も左も判らない私・・・

50 ：

>>47
マニュアルのこの部分を読んで設定してください。
http://www.pjam.jpweb.net/pgsql-doc/ej/user/sql-grant.htm
もし上のが意味不明に思えるなら下記の一連のスレッドをお読みください。
http://sidecar.ics.es.osaka-u.ac.jp/php-jp/archives/msg02923.html

51 ：

私の場合、pg_connect(user=postgres table=xxxx)
このuserはcreateuserでつくったのに、上記の同じエラーが
出るのですが、さっぱりわけがわかりません。
createuserを使うと、pg_passwdとpg_shadowのどちらのファイルに
記述されるんでしょう。
pg_shadowはテキスト・エディターで開いても、文字化けして読めません。

52 ：

バイナリファイルを開いて「文字化け」とはかわいいね。

53 ：

> うそ。１４１氏なら、文書の最後は。じゃなくて"."
句読点を「，」「．」にしてるやつ最高にうざい・・・・
# レスキューもまねして，．使ってたな。

54 ：

>>48
ありがとうございます。
早速上のマニュアルを参考に、テーブルのアクセス権を変更してみました。
GRANT ALL ON XXXX(テーブル名) TO PUBLICでenterしたら、
chengeのような表示が出ました。
もう一度ブラウザ上でファイルを読みだしたところ、今度は違うエラー表示です。
これは多分私が真似したスクリプトが違うようで、
Parse error:
parse error in /usr/local/apache/htdocs/ユーザー/test01.php3 on line 10
でした。これはスクリプトの10行目が何かおかしいよ、という意味で解釈してい
いのでしょうか。
もしそうなら、データベース自体への接続は出来たのかと一安心してます。

55 ：

>>51
pg_connectってtableの引数ないんじゃ？

56 ：

>>55
functionでおま。
問題は解決。
データベースのデータがページに出力されたのをみた瞬間、
ニヤリと笑ってしまった。ああ、プログラムの喜びよ（おおげさ）

57 ：

これからPostgreSQL+PHPの勉強を始めようと思います。
今まで少しだけWindowsでidc+htx+odbc+Accessという組合せでデータベースを
ウエブ上に表示させたり、そこから更新や新規登録などをかじってみました。
そこで質問ですが、idc+htxという組合せだと
サイト訪問者--->htmlファイル等で問合せ--->idcファイルが問合せの処理--->htx
ファイルにその結果を表示
という流れだと思うのですが、PHPの場合は
サイト訪問者--->htmlファイル等で問合せ--->phpファイルが問合せの処理+その処理
結果を表示
という流れと考えていいのでしょうか?

58 ：

>>56
ODBC ドライバ使って MS Access から pg のデータを
編集できたときもうれしかったですわ。
データを作るならこの方がやりやすいしね。
MySQL でもこういう子とできるのかな？

59 ：

できるみたい。
http://www.softagency.co.jp/mysql/Win/win.html
とりあえず試してみます。

60 ：

簡単にできた

61 ：

PHP側の問題としては、標準的なSQL要求に対してのグローバルな
インタフェースを用意できていないのが問題な気がする。
一度決めたDBを乗り換えようとした場合、ムチャクチャ大変でそ？
この辺、どーにかならんのかね…

62 ：

あと、MySQLってトランザクションが無い時点でいきなり候補から落ちない？
そもそも商用に使っていいんだっけ？

63 ：

>>61
PHP4 には一応抽象化 DB クラスがあったりしますね。
で、 PHP4 で増えたこのあたりの機能のことを見ようと 「PHP4徹底攻略」を
買ってきたんだけど、 DB 回りのサンプルは PHP3 対応の旧版とほとんど
かわってねーんでやんの。
セッション機能なんかもさらっと触れられてるだけだし。
巻末の役に立たないリファレンスなんかいらないからそのあたり詳しく
書いて欲しかった。

64 ：

>>63
あの本はダメだよねえ。というか PHP ユーザー会で Pear に取り組もうと
いう人が広川さん以外にいない時点で、かなり終わっているね。
最近はろくな活動もしていないみたいだし。
いつまでも『PHP + PostgreSQL による高機能 Web の構築』じゃないだろうに。
・どうやったら生産性を高めることができるか
　・どうやったら同じコードを何度も書かずにすむか
　・どうやったら同じバグに遭遇しないですむか
・どうやったら設計が簡単になるか
　・どうやったら設計情報を抜け漏れなく記述できるか
　・どうやったら設計情報を共有できるか
・どうやったら実装が簡単になるか
　・どうやったらビジネスロジック層と永続化層をきれいに分けることができるか
　・どうやったらオブジェクトの永続化が容易になるか
といった課題を解決していかないと、小規模案件の書き捨て用言語以上の存在には
ならないだろうね。で、最初のはクラスを使うことでかなり解決できるし、
二番目のは UML（+ Web 拡張）かな？という気もするし最後のは既存の方法論が
使えるし、十分クリアできるじゃーんとか思うんだけどなぁ・・・。

65 ：

>>63-64
言いだしっぺの法則の適用を望みます。
それを本気でやったらPHP界の英雄になれますよ。それだけでは食ってけないでしょうけど (苦笑

66 ：

>>65
うひゃあ！うっかり余計なことを言うもんじゃないなあ。
まあ何か出てきたらこの板にて書きますわ。
ちなみに PHP ユーザー会は日本語化についてかなり貢献していることにも
触れておかないと片手落ちだね（もともと日本語化のメンバーが中心だしなあ）。
だからクラスがどうのこうのよりも日本語化にしか関心がないという推測も
できるかもね。

67 ：

PEARのDB.php(pgsql.php)使ってみたけど、ちょい使いづらいぞ。

68 ：

age

69 ：

あれ・・・書き込まれない。リトライ。
>>67
なんのなんの、あれの原型になっていると思われる DBTools.h++ に比べれば
まだまだ素直でしょう。DBTools.h++ に興味があったら
http://www.roguewave.com/support/docs/dbtug/index.cfm
へどうぞ。
冗談はともかく、慣れの問題もあると思うよ。connect->exec->result->close という
手順に慣れていると fetch だのなんだのいったお約束は邪魔に感じるとは思う。
その印象は正しいと思う。
ただ、この手のクラスライブラリは
・どのデータベースにアクセスするにも同一の手順を使える
　-> 覚えることは一つでよい
・少なくとも Pear の中のロジックについては信頼して使える。
　つまりデバッグすべき範囲を限定できる
という点に大きなメリットがあるから、そのアプリケーションを PostgreSQL
以外の RDBMS に移植するとか、アプリケーションごとに異なる RDBMS を使う
必要があるといった場合にならないとメリットを感じられないかもしれない。
言い換えれば、RDBMS の実装を一つに固定してしまうなら Pear の DB クラスは
それほど威力を持たないということ。自分でアクセスクラスを書いた方が多分
便利だろうね。

70 ：

PEARのDB.php(pgsql)が使いづらいと思っている点。
使い方に誤りがある場合は指摘してください。
・$connectionを公開していないのでpg_set_client_encoding()などを行えない。
・query()もsimpleQuery()もその中でpg_numrows()を実行しているのに、
　再度numRows()を実行しなければ行数が分からない。
・Selectする手段がquery(), simpleQuery(), execute()と複数あり、迷ってしますう。
・遅い（単純なページで、ページあたり+20〜+30msかかる）
といったところです。もちろん、extendして自分でクラス定義してしまえばいいんですけど。

71 ：

遅いって、classとかで包容しようとするならそれは仕様つーか命題つーか。
ブラックボックスアプリがでかくなるのは当然でそれはシステムで補っていただきませう。
今書いてるモノだと、こいつは絶対エラーにならんから処理省いちゃえ的に
書くこと多いんであとで苦労することが多いんだよね。
classがそれを助けてくれるのなら大歓迎。
次のシステムで実験させて貰います。

72 ：

>>70
> ・$connectionを公開していないのでpg_set_client_encoding()などを行えない。
simpleQuery とかで simpleQuery("SET clientencoding TO 'EUC_JP'"); とか
して対処できない？
simpleQuery は単純に pg_execute(${simpleQuery の引数}) しているだけ
だからこれで動くと思うんだけど。
> ・query()もsimpleQuery()もその中でpg_numrows()を実行しているのに、
> 　再度numRows()を実行しなければ行数が分からない。
ソース見てちょっとびっくり。この辺の扱いって実装ごとに異なっているんだ。
ううむ・・・。
PostgreSQL 前提だと、Qeury のたびに DB_pgsql のインスタンス（仮に $pgsql と
するよ）の $numrows に行数が格納される。で、$pgsql->numrows[$result] で
アクセスできる。
肝心の $result だけど、simpleQuery の場合は単純にその戻り値を使えばいいし、
query() の場合には戻ってきた DB_result 型のオブジェクトの $result に
アクセスすればいい。例えば $resultObj->result とか。

73 ：

> ・Selectする手段がquery(), simpleQuery(), execute()と複数あり、迷ってしますう。
simpleQuery と query はともに直ちに実行可能な SQL 文を渡して処理するメソッド。
ただ、前者の場合には戻り値が pg_result で利用可能な結果識別子なのに対して、
後者は DB_result 型のオブジェクトが返るところが違うようだね。
execute() は prepare() とセットで実行されることが前提。で、prepare() に渡す
SQL 文には、? と & という特別なバインド変数を定義できて、前者の場合には
第二引数で渡された値（配列中の値）が、後者の場合には渡された値と同じ名前を
もつファイルの中身を SQL 文の中に結合することができるみたい。
> ・遅い（単純なページで、ページあたり+20〜+30msかかる）
>>71 さんのおっしゃる通りだと思う。
あとは Zend Cache 使うとか・・・。

74 ：

あぁぁー、すごい勘違いをしてた。
インスタンス変数って、プライベートだと思っていたら、パブリック
だったんですね。
道理で、アクセッサメソッドが無いわけだ。
それから、各メソッドの説明どうもです > 電動ナナシさん
prepare() & execute()の機能には、ビックリです。
>prepare():
>Prepares a query for multiple execution with execute(). With
>PostgreSQL, this is emulated.
じゃ分からんぞ(w

75 ：

>>72
>simpleQuery とかで simpleQuery("SET clientencoding TO 'EUC_JP'"); とか
>して対処できない？
simpleQuery("SET client_encoding TO 'EUC_JP'")
でOKでした。

76 ：

恥ずかしい質問なのでsage。
$ret = $db->simpleQuery("set client_encoding to 'EUC_JP'");
if ($ret != DB_OK) {
  exit;
}
とやったところ、エラーが発生してもexitしない。
これは、エラーが発生したときに、$retに文字列が入っていて、
比較するときに文字列->数値という変換がなされ、
if (0 != 0)
という比較になるので、このifブロックには絶対に入らない。
正しくは、
if ($ret !== DB_OK)
とする必要がある。
・・・という解釈は正しいですか？

77 ：

さらに疑問が。
(1)のエラー判定は、こうするしかないのでしょうか？
ほかに判断の方法はありますか？
require("DB.php");
$db = DB::connect("pgsql://localhost/testdb");
if (DB::isError($db)) {
  exit;
}
$sql = "select emp_code, emp_name from emp";
$res = $db->query($sql);
if (get_class($res) != "db_result") {    // (1)
  exit;
}
//echo $db->numrows[$res->result] . "<br>\n";
echo "<table>\n";
while ($row = $res->fetchRow(DB_FETCHMODE_ASSOC)) {
&nbsp;&nbsp;echo "<tr><td>$row[role_name]</td><td>$row[emp_name]</td></tr>\n";
}
echo "</table>\n";

78 ：

>>76-77
ちょっと今余裕がないので、1点だけ。
simpleQuery() は Protected な Method なんだと思う。
何でかというと、simpleQuery() の戻り値は実装依存になって、実装の詳細を
隠蔽しようという DB クラスの意図に反するから。
じゃあなんで simpleQuery() なんてあるのかというと、クラスを拡張するときに
実装を意識しないといけないときのためにあるんだと思う。言い換えれば、
extend したクラスからのみこのメソッドは用いられるということ。
だから DB クラスを普通のアプリケーションから使うときには query() を使って
DB_result 型の結果を取得し、fetchRow() するのが正しい使い方になるんだと思う。
ここのサンプルコードも見てみて。query() 使っているよ。
"Best Practices: Database Abstraction"
http://www.phpbuilder.com/columns/allan20010115.php3
エラー判定については後でね。

79 ：

>>78
電動ナナシさん、毎度どうもです。
PHPBuilderの記事をざっと読みました。
# ここ、良い記事がたくさんありそうですね。
そして、わかった＆考えたこと。
・ DB.phpの思想は、DB::isError($obj)でエラー判定をする。
・ そして、DB::errorMessage（$obj)でエラーメッセージを獲得する。
・ mysql.phpは確かに、query()が失敗すると、raiseError()している。
・ ところが、なぜだかpgsql.phpでは、query()が失敗すると、直接エラー
　メッセージを返している。
・ なので、DB::isError(query())というお決まりパターンが使えない。
他のDBのライブラリを全部見たわけではありませんが、DB.phpの
isError()の実装を見る限り、pgsql.phpの実装に一貫性が欠けている
気がします。

80 ：

うーん、ソースをちらっと眺めたところ、DB::isError() -> DBerrorMessage()
のしくみがきちんと機能するのは、MySQLだけみたいな気が。
>>79は間違っているのかなぁ？

81 ：

というか、ソースなんぞ見なくても、サクサクプログラミングできるのが
PEARの目標だと思うのだけれど・・・。

82 ：

>>81
そうなんだよね。まだまだ発展途上。ドキュメントもないし。
そのうちクラス図を作って公開する予定。
>>80
>>79 は合ってる。それで正解。というか DB に限らず PEAR 共通の例外機構のような
ものを作りたいみたいなんだよね。で、
・メソッド実行して、成功なら普通のオブジェクトを、失敗なら PEAR_error 型の
　オブジェクトを返す
・オブジェクトについて isError($returnedObject) で成功・失敗を判定
という風にしたいような感じなんだなあ。
MySQL と OCI8 は確かにエラーが起きると raiseError() して DB_error 型
（こいつは PEAR_error を継承している）を生成して返すようになっているけど、
DB_pgsql.php はそうなっていないという点が問題みたい。
広川さん（DB_pgsql の開発者）に連絡するか、自分でパッチ送って submit すると
喜ばれるんじゃない？自分も暇が出来たらやってみよう。

83 ：

あー、でも PostgreSQL ってエラーコードがない（errorMessage() で取得する
しかない）んだよね。それで実装されてないって可能性が大きいかも。
DB_pgsql.php の errorNative() のコメントを見てそう思った。

84 ：

PHP-jp見てて、
http://lxr.php.net/source/php4/pear/DB/pgsql.php
を発見しました。
・・・ォィォィ、おもいっきり、実装かわっとるやん。
とりあえず、simpleQuery()でエラーが発生した場合、raiseError()
しているのを確認しました。
# pgsql.phpには、query()が無くなってます。
PHPもPostgreSQLも最近始めたばかりで、php-mlの近藤氏が
どのような人かは知りませんが（でも、発言力ありそうな雰囲気）、
> ソースコードをみて、バリバリ自社で保守するだけの
> 技術力と体力のあるとこは別だけど、私なんか、とて
> も使う気になれません。テストも終ってないコードを
> 使う位なら、レベルは低くても責任もってユーザー
> サポートできる自前のツールの方がいいです。
というのは悲しいね。
DBの抽象化ライブラリとして現在も標準添付されているし、
おそらく将来もそうであろう「PEAR」なんだから、
どんどん使って、ノウハウを溜め込み、その思想を学ぶ
べきなんじゃないかなぁ、なーんて、思いますけど。
sourceforge.netを見ても、PHPのDB abstract libraryは
両手でも足りないくらい（ウソかも）あり、とても全てを
評価するなんて出来ません。
みんながそれぞれ、ちょっとづつ違うDBライブラリを作るなんて、
それこそ非生産的です。
# ところで、PEARのアノニマスCVSリポジトリってあるんでしょうか？

85 ：

> # ところで、PEARのアノニマスCVSリポジトリってあるんでしょうか？
検索したら、ありました。（先に検索しろ＞自分）
cvsweb:
http://cvs.php.net/viewcvs.cgi/php4/pear/
pserverもありました。

86 ：

>>84
あなた、すごいね。:-)
近藤さんの言いたいことも分かるけど、
> みんながそれぞれ、ちょっとづつ違うDBライブラリを作るなんて、
> それこそ非生産的です。
これに大いに賛成。
ただ近藤さんが一番心配しているのは SQL (DDL/DML) の互換性の問題だと思う。
サブセレクト（副問い合わせ）の対応の有無とか、トランザクションの
構文とか、ロックの構文とか実装によって全然違うからね。
# 先の PG_CLIENT_ENCODING もその問題の一つ。
だからデータ操作まで完全に抽象化するのに Pear じゃダメというのはある程度
理解できる。
ただ、アクセス方法やエラーハンドリングを標準化する意義は十分あると
思うなあ。JDBC に批判的なように、近藤さんはこの手の抽象化ライブラリ
全般に不信感があるのかもしれない。
# ODBC では確かにひどい目にあったな。
コードの信頼性は、チャレンジャー（人柱）の犠牲によって獲得していく
しかないだろうね。すると人柱が一番多いのはどれだ？という話になると
思う。今のところ PHPLib > Pear >> その他 という感じかなあ。

87 ：

>>86
Abstract DB Libraryの目的（ターゲット）としては、例えば
SQL92 Entry Levelとかを想定して、実装していけばいいん
じゃないかなー、なんて思います。
ここ数年Oracleをやってきたんですが、最近PostgreSQLを始めて、
特にそう思います。
PEARのDBライブラリは、OracleのBC4Jなどと違って（BC4Jの
場合、DMLを一切使わずにプログラミングします。もちろん、
使おうと思えば使えます）、DMLは自分で書く、というスタンス
なので、DBの違いによるSQLの違いはライブラリ側で吸収する
必要が無いのです。
DBライブラリは、SQLをDBに送って、結果のレコードセットなり、
完了値を戻せばよいのです。
PHP-jpを見てて思うのは、クライアントアプリケーションの機能を
実現するためのコードと、ライブラリのコードをごっちゃに論じて
いる気がします。
現時点で言えば、例えばOracleとPostgreSQLを同じDBライブラリを
使って同じコードで、どちらのDBでも動くようにしようと思うのなら、
ViewやストアードサブプログラムやトリガーなどのDBエンジン内の
仕組みを駆使するしかありません。もちろん、それらのDBエンジン
側のプログラムやDDLのコードは、各DBで違うのですけど。
PEAR（というか、抽象化DBライブラリ）を使えば、クライアント
アプリケーションのコードは同一で、複数DB対応は可能だと思います。
もちろん、DB管理ツールなどは、同一のコードなどは望むべくも無く、
ゴリゴリにターゲットDBに依存しまくったものじゃないと使い物に
ならないんじゃないかなー。
なんか、とりとめが無くなってきたのでこのへんで。

88 ：

>>86
>ただ、アクセス方法やエラーハンドリングを標準化する意義は十分あると
>思うなあ。JDBC に批判的なように、近藤さんはこの手の抽象化ライブラリ
>全般に不信感があるのかもしれない。
それは、よーくわかります。
>コードの信頼性は、チャレンジャー（人柱）の犠牲によって獲得していく
>しかないだろうね。すると人柱が一番多いのはどれだ？という話になると
>思う。今のところ PHPLib > Pear >> その他 という感じかなあ。
私はPHP4.0.4から入ったので、PHPLibは使ったことないのですが、
それに慣れて、しかも発言力ある人たちが、「Pearは不安定だ、
未完成だ、使えないぞー」と声高に（というのは私が受け取った
印象ですが）言うのは、やめて欲しいなー、という感じですね。

89 ：

PearはCVSで追っかけることが出来るようになったんですが、
なにしろ、時間が無い・・・。来週末までに、今作っているシステムを
完成しないといけないんです（グチ）。
誰か最新版を追っかけて、評価する人いないかなー。
# 結局、他人を頼るのかいっ! (w

90 ：

新しいマニュアルをダウンロードしたら、PEARの章が出来てました。
忙しい人の為に、目次を引用。
V PEAR: the PHP Extension and Application Repository
23 章 PEARについて
- PEARとは?
24 章 PEAR コーディング標準
- インデント
- 制御構造
- 関数のコール
- 関数の定義
- コメント
- コードの読み込み
- PHPコードのタグ
- ヘッダのコメント部
- CVS タグ
- URLの例
- 定数の名前
LXXXIII PEAR リファレンスマニュアル
- PEAR PEAR基底クラス
- PEAR_Error PEARエラー処理機能の基底クラス
やはり、PEARのエラーハンドリングの思想は、エラーオブジェクトを
返す、というので正解でした。

91 ：

>>84
query() は DB_common.php に移動したみたいだね。で、query() では simpleQuery() を
中で呼び出して使っている。こっちの方がエレガントでいいよなあ。
# Refactoring だね。:-)
>>87
思いっきり同意。
「何をクラスライブラリで共通化するか」という議論が抜け落ちている感じがするね。

92 ：

たびたび申し訳ないです。
>>48と>>50で教えていただきました方法を試してみました。
GRANT SELECT ON (VIEWのテーブル名） TO PUBLIC;
ですが、この場合PUBLICとは誰にでも許可するというような意
味合いと解釈したのですが、実際にはまだエラーが続いてしまい
ます。
nobodyは上記publicとは全く別者なのでしょうか？
GRANT SELECT ON (VIEWのテーブル名） TO nobody;
とする必要があるのでしょうか？（実際試してみればいいとは思
うのですが、何か解説等があれば教えていただきたく思いました。）

93 ：

>>92 ...to public なら、全てのユーザーに許可されます。
postgresアカウントでcreateuser nobodyしてみました？

94 ：

>>93 ありがとうございます。
おっしゃる通り、nobody自体のアカウントが作成してありませんでした。
目標とする結果はブラウザ上に現れませんでしたが、今回は間違いなくDB
への接続は出来ているようです。
私のスクリプトが間違っていると思われ、ブラウザ上には何もエラーメッセ
ージは出ませんが、画面は真っ白でした。
今度こそ、ゆっくりスクリプトの方に挑戦してみます。
また判らないことありましたらお伺いさせていただきます。

95 ：

只今スクリプトの間違いを訂正して、ようやくDBからのデータ出力が出来ました。
まだ勉強を始めたばかりのため、複雑なSQL文やPHPのスクリプトは書けませんが、
取り敢えずブラウザ上にデータが表示されたことには感動しました。

96 ：

お尋ねです。PHPで金額の表示をしたいのですがどうすればいいでしょうか。
例）1000 → 1,000 のように。
お願いします。

97 ：

>>96
number_format()

98 ：

>>97
金額の表示ＯＫでした。
どうもありがとうございました。

99 ：

なかなかよさそうなページ発見。
http://www.zend.com/codex.php?CID=10
英語では、「抽象化DBクラス」を「Database Abstraction Class」って
言うみたいですね。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

perlスクリプト⇒phpスクリプト移植要望スレ (610)
PHPの使える鯖 (146)
Zopeってどうよ インスタンス4つめ (382)
WebProg板出席簿(寂) (256)
おいおまら誰か教えてくださいHTML・・・ (256)
アップローダースレ Part3 (784)
--log9.info------------------
■昔の秩父鉄道　東武熊谷線を語ろう■ (251)
【なりきり】現在、1976年（昭和51年）【スレッド】 (974)
■　なつかしの阪神電鉄　■ (432)
古い時刻表持ってんだけど何か質問ある？ Part11 (441)
三河島事故＆鶴見事故＆餘部鉄橋事故 (353)
国鉄分割民営化は失敗だった IV (679)
【内田から阿川】阿呆列車　２号【そして鴫州へ】 (198)
なつかしの駅弁 (783)
ぬるぽを2時間以内にガッ@懐かし鉄道板 46輌目 (183)
急行のマイナーな停車駅 (125)
【今は亡き】ドリームランドモノレール【東芝式】 (488)
〔昭和〕ここだけ30年前のスレ〔鉄道懐かし板〕弐 (823)
続、垂れ流し便所 (787)
非冷房車はなんで暑いの？ (586)
【国鉄時代】乗り換えゲーム【私鉄可能】7路線目 (413)
｜｡￣＼ EF58 35／￣｡｜ (859)
--log55.com------------------
DVD-RAM普及するに至らず時代はBDへ
【日本語対応】 DVD FAB Gold【完璧な2枚分け】
Fortis Part5
☆福岡のCDR事情3rd☆
Pioneer ±R/RWﾄﾞﾗｲﾌﾞ「DVR-A10J・110系」 Part10
買ってきたDVDメディアのIDを晒すスレ -3枚目-
CloneDVD 2 ＆ mobile でどうよ？
【S-ATA】ASUSTeK DRW-1814BLT part.1【RAM14倍速】