Perl::DBI
■ このスレッドは過去ログ倉庫に格納されています
256倍本で DBI のが出たね。 まだ見てないけど。 ところで、Perl::DBI って書き方あるの? DBI256倍は14日発売じゃなかったか? Perl::DBIは今考えた。 Perl-DBIとかPerl/DBIじゃしっくりこないかと思って。 >>5 売っているのを見たってだけで、中を見たわけじゃない。 すまん。 >>7 ,6 買ってみることにするよ これもいちおうはとこう 「入門 Perl DBI」(Programming the Perl DBI) http://www.oreilly.co.jp/BOOK/perldbi/ ∧∧ (^▽^) 新スレおめでとうございまーす♪ ヾcUUっ Perl 256 DBI編は「DBIを使うため」の本じゃなくて「DBDを作るため」の本ですね。 マニアな内容でイイです。 まだ前半しか読んでないけど、英訳すれば英語圏でもちゃんと売れそうな内容っすね。さすが。 で、ジョーク(?)が日本固有なものじゃないのは、著者の川合さんがその辺を想定してるからかな。 読みました。 EffectivPerlわかるくらいのひとなら かなりおもしろいはず。 DBIて奥深いね。 やっと入手。 流石に濃いね。 でも256本の特徴なのか <BIG>こんなの</BIG> が沢山あるのが読みにくい…。 MySQLについて詳しい書籍はないでしょうか? PostgreSQL本はよく見かけるんですが… 補足です、PerlでMySQLを使いたいのです。 PHPとの組み合わせがメインのものが多くて・・ レスが・・・ >>17 ありがとうございます。 ネット上の資料を点々としていました。 早速明日本屋に寄ってきます。 DBDを書くのって馬鹿みたいにメンドクサイのだが、 この辺の構造に誰も文句いったことないんかね? >>19 まぁ、Tim神の怒りをかったら終わりだからなぁ。 本発見、MLの人だ。このシリーズ、最近紙質落としてなかたけ >>25 なぜそう思ったのか400字以内で説明せよ。 Cマガジンで Perl DBI の連載が始まる (始まった?) らしいね。結城さんの連載と入れ替わりなのかな。 読んだヒトいる? 漏れはプローガ先生の記事が無い Cマガは買う気がしないけど。 なんか今日会社にきた取引先の人が、 MYSQL+Perl(DBI/DBD)で開発することについて 「そのようなやり方は聞いたことがありませんねぇ。 普通はMYSQL+PHPですよ。」 とか言ってたんだけどそんなにMYSQL+Perl(DBI/DBD) ってマイナーなやり方なのかな? それともそいつが勉強不足なだけ? 彼の「普通」がそうだっただけ。 ドメインによって色々な「普通」有るからなぁ。 大抵の奴が自分の属しているドメインの「普通」が 普通だと思ってるからたちが悪い。 つーかその人Web関係のSEらしいんだけど、 もうちょっと勉強しろと言いたい。 >>29 単に Perl を避けているだけでは? 漏れの周りには、 「Perl ってモジュールとか入れなきゃいけないか ら面倒じゃないですか。PHP が簡単だから PHP に しましょうよ」なんて言うヒトもいる。そんなレベ ルの話じゃないのかな? 「普通」なんて言い方は、自分の常識を押し付けた いときに使うよ。漏れの場合(w 確かにMySQL+PHPと比べた場合MySQL+Perl(DBI/DBD)のが面倒に思える もっとDBI/DBDは知られてほしいなぁ。 PostgreSQLのシーラカンス本では、Ruby、JSP、PHPなどとの 連携は紹介されているのにPerlとの連携に関しては触れられてない。 なんでだよ! なんとなくMacOSX 10.2にperl+postgresqlの環境を作ろうと 思ったのですが、DBIとDBDのモジュールのインストールが 難しい。よく分からないエラーがでてしまいます。 成功してる人、教えて!!! >>38 「よく分からないエラーが出てしまいます」じゃ誰だって教えられないよ。 >>39 いや、もちろんそうなんだけどね。 どのようなエラーが出るかちゃんと報告すれば ちゃんと教えてくれるから。>>36 なぜWebプログラミング板でこのスレが上がってこないんだ? DBD::CSV DBD::File 排他処理が不安で使ってない香具師 WebProg ったって個人サイトの掲示板みたいなのも含まれるだろうしね。 ログ100件ぐらいだったらファイルで充分だったりする。 数千件 数万件でもやりようによってはCSVで十分な パフォーマンス出せたりする。 DBI DBDはインストールできればあとはSQLの書き方なわけで DBIは常用していても話題がないのよ。 >>45 最近、DBD::CSVがバージョンアップしてJOINもできるようになったYO! とか色々あるだろ。なんか、PHPはDBとの連携ができるけどPerlは できないとか変な偏見があるみたいだからちょっと悔しかったりする。 >>46 そんな偏見ははじめて聞いたが……。 悔しいことは悔しいね。 んで、DBD::CSVのロック機構はどうなってるの? 悔しい? かわいそうな人達なのでやさしく教えてあげてください。 >>32 Perlはプログラマによって非常に観やすくいい仕事するCGIと 非常に乱雑で適当に仕事するCGIに大きく分かれるよね。 PHPもエラーメッセージがブラウザで確認されてしまうのが厄介。 (というかカッコワルイ) CPANモジュールも普通にXで使うのなら便利なんだけど・・ ウェブサイト用CGIとして使うと余計なモジュールが多すぎてヘタすりゃ いらないモジュールまで取り込んでしまうプログラマもいるみたい。 (そういう人は影で笑っておけば・・・済まないか w) >>49 >PHPもエラーメッセージがブラウザで確認されてしまうのが厄介。 >(というかカッコワルイ) 貴殿はPHPを使ったことが無いとお見受けしました。 >>49 いらないモジュールuseしても問題ないだろ。 >CPANモジュールも普通にXで使うのなら便利なんだけど・・ xで使うねぇ・・・ 貴殿はちょっとLinuxかじった房 だとお見受けしました。 >>52 > いらないモジュールuseしても問題ないだろ。 いやー、問題ないとは言えないでしょ。 メモリの無駄だし、標準関数をオーバーライドするモジュールもあるし。 インストールは、ディスクが無駄な以外問題ないと思うけど。 >>49 の「取り込む」の意味が不明なので話の前提がわからんが、 49がアレだというのには同意する。 勉強するには本を買うしかないのですか? なんにも分かってない状態なので、 とりあえず“入門Perl DBI”を注文してあるのですが、 それが届くまでの間、どこかに分かりやすいサイトがないものかと。 いろいろ見て回ったものの、正直、ぜんぜん理解できませんでした・・・ ってことは、本を買っても理解できないってことになるのだろうか・・・ あと、入門書として“入門Perl DBI”は最適でしょうか? インポート無しでuseすれば名前空間は汚れないし。。 自分の空間にしかインポートされないから、勝手に汚染されることはないじゃろ。 どうせモジュールなんてmod_perlがキャッシュしてくれるから、分かりやすいように書けばよろしい。 use hogehoge (); あぁ文章がめちゃくちゃだった。。 もっとまともな説明は、 use モジュールの名前 (インポートする関数名のリスト); 2つ目のリストが省略されたら、モジュールのデフォルトのものがインポートされる。 もちろん、デフォルトが何もインポートしない、になっているかもしれない。 つまり、、、 use Module () と、require Moduleは、いつ読み込まれるか、っていう違い(コンパイル時、 実行時)はあるけれど、結果的には同じことがおきる。 object の package って require しても使えるんだっけ? use → モジュールが読み込まれ、関数が自動的にインポートされる。返り値は? require → モジュールが読み込まれるだけで、インポートはされない。成功すれば真の値をかえす。 という理解でいいかな。 マジレスすると use Module @list は BEGIN { require Module; Module->import(@list) } と等価、 no Module @list は BEGIN { Module->unimport(@list) } と等価だ。 import 関数は Perl 標準の Exporter モジュールから 継承してるケースが殆どだから、シンボルの輸出入に 関する仕組みは Exporter の POD を読めば理解できる。 しかし import を自前で実装してるモジュールもあるし、 require した段階で main パッケージに割り込む行儀の 悪いモジュールもある。よって use Module (); で確実に 輸入規制ができるとは限らない。 use は sub NAME と同じく宣言だから戻り値は無い。 my $rv = use Module; は構文エラーになるし、無理矢理 my $rv = eval { use Module; }; 等としても undef が入るだけ。 あぁ。そうかぁ。require時の初期化の時点で勝手に割り込むやつもいるのか。。 このあたりは、Perl教なら、リビングの法則でなんとか説明するところかな。(?) DBD::Access誰か作ってくれないかなぁ。 てゆーか誰も作ってないってことは難しいのかなぁ。 ODBC 経由では無理だった?もしくは、ADOとか。 >>68 いや、今はWindowsXP+ActivePerl+DBD::ODBCなんですけど、 例えばLinuxのレンタルサーバーのUserディレクトリとかで 手軽に使えたらいいなーって思ったんですけど。 SELECT文実行後にfinish しないとまずいですか? prepare_cachedを使うときはfinishしないと駄目。かも。 Perlを256倍使うための本DBI編買ったよ。 てゆーかPerlの256本ってこれだけだよね? Rubyはいっぱい出てるのに。 DBD::CSVはPure PerlだからTelnet使えないレンタル鯖で 使えるかと思いきや、中でText::CSV_XS使っているという罠。 DBD::Template使ったことある香具師いる? あれいいね。 ━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━― ∧_∧ ピュ.ー ( ^^ ) <これからも僕を応援して下さいね(^^)。 =〔~∪ ̄ ̄〕 = ◎――◎ 山崎渉 どうしてもCSVファイルにDBI使いたくてDBD::CSVやDBD::Spriteを 試したんだけど、どうしてもベンチマークとると速度が遅い。 やっぱりSQL解析部分で時間食うみたいだった。 しょうがないのでSQL解析部分を自作して速度の問題を解決。 DBDは一から作るのめんどいのでDBD::Templateを使いました。 もうこれからは掲示板だろうがなんだろうがDBI使い倒してやる。 >>82 速度改良されたpmファイルアップキボンヌ DBD::Templateを使ったサンプルをUPしておきました。 SQL解析部分は見てもらえば分かりますが「ナンチャッテSQL解析」なので、 自分のプログラムに合わせて処理を付け足す必要があります。 速度とプログラムの汎用性という意味では自分的には実用的かと思います。 http://webcolle.minidns.net/perl/ >>85 すばーらスィ!!!!!! sql文の練習に使えます。ありがと。 こんど、オンラインでやってみます。 postgressql+pg.pmでやるのとどっちが速いかは、 やっぱデータ量によるんでしょうね。 >>86 所詮データはCSVファイルなので本物のRDBMSとは比較になりません。 ・CSVに対してSQLが使える。 ・DBIを使うことでプログラムの汎用性がある。 ・速度的にも掲示板のログ管理程度なら実用レベルである。 ・PurePerlなのでレンタル鯖等でも使える。 メリットはこんなところでしょうか。 ちなみにテーブル定義とSQL解析はプログラムごとに 付属のdbisub.plをいじらなければなりませんので。 >>87 ところで、川合さんの「PerlでDBI」(256倍シリーズ)買ったけど、ちょちょっ と見ると、DBDの分類で、「自作系 (1)sqlの解析にSQL::Statementを利用」 の中に、DBD-CSVってのがある(DBD-Fileを継承)けど、>>85 のは、それの兄弟 のようなものかね。 DBD-Templateは河合さん作です。 ↓のURL見た方が早いかもしれませんが、中身は本の中で紹介されてた SomeFmt.pmを少しいじっただけだと思います。 http://www.hippo2000.info/cgi-bin/KbWiki/KbWiki.pl?cmd=disp&page=DBD%3a%3aTemplate なんか作者でもないのに勝手に宣伝してるみたいでなんか 悪いことしてる気がしてきた・・・ __∧_∧_ |( ^^ )| <寝るぽ(^^) |\⌒⌒⌒\ \ |⌒⌒⌒~| 山崎渉 ~ ̄ ̄ ̄ ̄ ∧_∧ ∧_∧ ピュ.ー ( ・3・) ( ^^ ) <これからも僕たちを応援して下さいね(^^)。 =〔~∪ ̄ ̄ ̄∪ ̄ ̄〕 = ◎――――――◎ 山崎渉&ぼるじょあ 誰かDBD::Access作ってよ。 DBD::ODBC使えって?UNIXでも使いたいんだよ。 DBIでトランザクション処理ってどのようにやるんですか? AutoCommit をoff(0)にしたら それ以降は、commit するまで1つのトランザクション ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる