元スレPHP + PostgreSQL
php覧 / PC版 / みんなの評価 : ○
前へ
52 = :
バイナリファイルを開いて「文字化け」とはかわいいね。
56 :
>>55
functionでおま。
問題は解決。
データベースのデータがページに出力されたのをみた瞬間、
ニヤリと笑ってしまった。ああ、プログラムの喜びよ（おおげさ）
59 = :
できるみたい。
http://www.softagency.co.jp/mysql/Win/win.html
とりあえず試してみます。
60 = :
簡単にできた
61 :
PHP側の問題としては、標準的なSQL要求に対してのグローバルな
インタフェースを用意できていないのが問題な気がする。
一度決めたDBを乗り換えようとした場合、ムチャクチャ大変でそ？
この辺、どーにかならんのかね…
62 = 61 :
あと、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 ユーザー会は日本語化についてかなり貢献していることにも
触れておかないと片手落ちだね（もともと日本語化のメンバーが中心だしなあ）。
だからクラスがどうのこうのよりも日本語化にしか関心がないという推測も
できるかもね。
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 クラスは
それほど威力を持たないということ。自分でアクセスクラスを書いた方が多分
便利だろうね。
71 :
遅いって、classとかで包容しようとするならそれは仕様つーか命題つーか。
ブラックボックスアプリがでかくなるのは当然でそれはシステムで補っていただきませう。
今書いてるモノだと、こいつは絶対エラーにならんから処理省いちゃえ的に
書くこと多いんであとで苦労することが多いんだよね。
classがそれを助けてくれるのなら大歓迎。
次のシステムで実験させて貰います。
81 = :
というか、ソースなんぞ見なくても、サクサクプログラミングできるのが
PEARの目標だと思うのだけれど・・・。
88 = :
>>86
>ただ、アクセス方法やエラーハンドリングを標準化する意義は十分あると
>思うなあ。JDBC に批判的なように、近藤さんはこの手の抽象化ライブラリ
>全般に不信感があるのかもしれない。
それは、よーくわかります。
>コードの信頼性は、チャレンジャー（人柱）の犠牲によって獲得していく
>しかないだろうね。すると人柱が一番多いのはどれだ？という話になると
>思う。今のところ PHPLib > Pear >> その他 という感じかなあ。
私はPHP4.0.4から入ったので、PHPLibは使ったことないのですが、
それに慣れて、しかも発言力ある人たちが、「Pearは不安定だ、
未完成だ、使えないぞー」と声高に（というのは私が受け取った
印象ですが）言うのは、やめて欲しいなー、という感じですね。
89 = :
PearはCVSで追っかけることが出来るようになったんですが、
なにしろ、時間が無い・・・。来週末までに、今作っているシステムを
完成しないといけないんです（グチ）。
誰か最新版を追っかけて、評価する人いないかなー。
# 結局、他人を頼るのかいっ! (w
94 :
>>93 ありがとうございます。
おっしゃる通り、nobody自体のアカウントが作成してありませんでした。
目標とする結果はブラウザ上に現れませんでしたが、今回は間違いなくDB
への接続は出来ているようです。
私のスクリプトが間違っていると思われ、ブラウザ上には何もエラーメッセ
ージは出ませんが、画面は真っ白でした。
今度こそ、ゆっくりスクリプトの方に挑戦してみます。
また判らないことありましたらお伺いさせていただきます。
95 :
只今スクリプトの間違いを訂正して、ようやくDBからのデータ出力が出来ました。
まだ勉強を始めたばかりのため、複雑なSQL文やPHPのスクリプトは書けませんが、
取り敢えずブラウザ上にデータが表示されたことには感動しました。
みんなの評価 : ○
php一覧へ類似してるかもしれないスレッド
- PHP PHPって (73) - [24%] - 2016/1/21 13:46
- Mac OS X + PHP + MySQL (199) - [21%] - 2022/3/13 12:00
トップメニューへ / →のくす牧場書庫について