PHP質問・雑談スレ 2【初心者お断り(ROM歓迎)】©5ch.io
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん 転載ダメ©2ch.net
2016/10/17(月) 21:44:12.59ID:???初心者お断り(ROM歓迎)と書いてますが、初心者用のスレが用意されているからで、
難しい質問や話題をしなければいけないわけではありません。
PHPマニュアルの読み方を概ね理解していて、関数リファレンスが正しく読める方用のスレです。
PHP未導入の方や、手取り足取りが必要な初心者の方はム板のくだスレへどうぞ。
http://echo.2ch.net/tech/ (【PHP】で板内を検索)
前スレ
http://tamae.2ch.net/test/read.cgi/php/1461283091/
その他リンク
・PHPマニュアル
https://secure.php.net/manual/ja/index.php
・コードテスト・貼り付け用
http://ideone.com/
・プログラミングのお題スレ Part8 （求PHPer参戦）
http://echo.2ch.net/test/read.cgi/tech/1444216746/
このスレで扱う話題
・PHPのコード，設定や設定値に関する質問
・常識的範囲内でのコードレビュー依頼・改良相談
・PECL，PEARに関する質問
・PHP新機能やPHP関連トレンドの話題
（FWや非公式ライブラリの話題や特徴比較は良いが使い方から先の話題は専スレへ）
・PHPのバグ発見報告・公式に報告する前の検証依頼
このスレで扱わない話題
・直接関係ない○○特有の質問（専スレへ）
（HH，エディタ，IDE，サーバ，OS，DB，SQL，FW，テンプレート，非公式ライブラリ・アプリケーション等）
・PHPの改造
0002nobodyさん
2016/10/17(月) 21:48:16.11ID:???猿
蟹
サル
カニ
ガニ
ゴミクズ
0004nobodyさん
2016/10/17(月) 22:49:19.07ID:???俺が書いたO/Rマッパーの場合、IN句に対応するコードは14行だな。
14行で渡される値がIN句に適切かどうか、SQLインジェクション対策から各種データベースへの汎用対応まで全部やってる。
勿論、ifやforeachみたいなのはちゃんと一行としてカウントしてるよ。
お前が書くコード、どんなことになってるの？
ちょっと説明してくれないか？
なぁ、そろそろ聞いていいか？
お前、越前ガニ君じゃないのか？
これほどのアホが、二人も三人もいる事自体が理解できん。
0005nobodyさん
2016/10/17(月) 22:51:35.98ID:???IN句で渡された値がWhere句に相当する条件でもその通りにクエリビルドする。
それでも14行だ。
エセ関西弁は、一体、どんなクソコードを書いてるんだよ？
0006nobodyさん
2016/10/17(月) 23:03:10.93ID:???暇ならパズルSQL問題出すけど解いてみる？
おまいさんのいうo/rマッパーを使って解けるかためしてみるとええで。
世の中にはo/rマッパーでは到達できないSQLがあるんやで。
0007nobodyさん
2016/10/17(月) 23:04:47.75ID:???0008nobodyさん
2016/10/17(月) 23:10:45.93ID:???>世の中にはo/rマッパーでは到達できないSQLがある
ということと、お前がO/Rマッパーを作れる／使いこなせるという事は全く別の事だとなぜ理解できない？
都合が悪くなったらあっちのスレは無視するお前が、まともにSQLが使いこなせていると
どうして他の人間に説得出来ると思うんだ？
それに、O/Rマッパーは只のクエリビルダーではないから、
通常、ナマのSQLも受け付ける。渡された配列をbindする形でな。
おまえのごたくは聞き飽きたとなんか言わせれば済む？
お前は頭が悪すぎるんだよ、致命的に。まだ気づかないのか？
0010nobodyさん
2016/10/17(月) 23:15:47.33ID:???おまいさんが作ったo/rマッパーの仕様なんか知らんで。
ついでに言うならo/rマッパーを作れる能力があるとして、それが今どこかで役に立つかっちゅーと全く役に立たんで。
クエリビルダーなんぞ今はどのフレームワークにもあるけんの。
しかし、SQLパズルを解ける能力は完全に業務遂行能力と1対1で紐付くで。SQLパズルを自動的に解いてくれるo/rマッパーなんか存在せえへんからな。
やってみる？ 意外と楽しいぞ。
0011nobodyさん
2016/10/17(月) 23:24:43.54ID:???どのフレームワークにもあることが、どうして、今の話題に何か関係があると思った？
>しかし、SQLパズルを解ける能力は完全に業務遂行能力と1対1で紐付くで。
そんなゲームが実務とどれほど密接に結びつくと、どうして思った？
O/Rマッパーに必要なのは、
「出来るだけ簡単にクエリビルドできること」
「場合によってはクエリの生成をプログラマに委ねるる事が出来る事」
の二つだ。
お前みたいなゴミクズの出番はねーんだよ、ひきこもってろ、野猿。
>やってみる？ 意外と楽しいぞ。
おめーの快楽なんてどーでもいいんだよ。一生一人でオナニーしてろ、サル
0013nobodyさん
2016/10/17(月) 23:31:50.36ID:???（マクドナルドのセットメニューなんかがそう）とか、特定の商品には異なる税率が掛かってお会計が変わったり、
あるいは特定の商品を三つ買ったら千円となったりするようなリアル金勘定と絡んでくるんだよ……！
一度そういう業務をやってみればわかるぜ。マジカルSQLこそが正義であるということに……！
（ここはPHPスレなので全く関係のない話なのだが）
0014nobodyさん
2016/10/18(火) 00:09:10.50ID:???まだ、そえれがO/Rマッパーと関係あると思ってるのか。
おまえ、本当に一回死んだほうがいいよ。向いてない、この業界に。
0015nobodyさん
2016/10/18(火) 00:38:18.88ID:???ORMならまぁわかるが
0016nobodyさん
2016/10/18(火) 01:14:21.67ID:???特に、最新環境にはこだわりませんので、５．ｘ系でも、７系でも良いです
簡単に構築・維持が出来る方が良いです
0018nobodyさん
2016/10/18(火) 03:11:02.71ID:???結局末端までの依存関係を気にしながらrequireすべし派の解説はないままっぽいかな？
0019nobodyさん
2016/10/18(火) 08:20:01.66ID:???0020nobodyさん
2016/10/18(火) 10:13:16.66ID:???場所？
なら、ここ
PostgreSQL RPM Building Project - Repository Packages
https://yum.postgresql.org/repopackages.php
0022nobodyさん
2016/10/18(火) 10:24:38.74ID:???0024nobodyさん
2016/10/18(火) 10:32:22.73ID:???> そんなゲームが実務とどれほど密接に結びつくと、どうして思った？
お前それこれ見ても言えんの？
http://www.geocities.jp/oraclesqlpuzzle/
0025nobodyさん
2016/10/18(火) 10:34:26.77ID:???0026nobodyさん
2016/10/18(火) 11:20:41.64ID:???0027nobodyさん
2016/10/18(火) 13:23:36.08ID:???0028nobodyさん
2016/10/18(火) 14:01:02.93ID:???統計によると、ほとんどが5.3か5.4らしいけど
0029nobodyさん
2016/10/18(火) 14:18:03.74ID:???この統計だと、5.3と5.4あわせても10%未満だな
https://seld.be/notes/php-versions-stats-2016-1-edition
0033nobodyさん
2016/10/18(火) 14:57:38.88ID:???もうそうやって議論内容ではなく人と戦ってる時点で
純粋な議論ではなく人を批判したいとかマウンティングしたいって精神が現れてるんだよ
0034nobodyさん
2016/10/18(火) 15:03:43.35ID:???そういうことしても使えないという意味で言ったわけではないからな
相手の意図をいつまでも理解できない奴のようだが
0035nobodyさん
2016/10/18(火) 15:05:06.45ID:???0036nobodyさん
2016/10/18(火) 15:25:16.76ID:???0037nobodyさん
2016/10/18(火) 16:02:52.15ID:???何言ってるんだ。
0039nobodyさん
2016/10/18(火) 16:41:36.66ID:???お前PDOが何なのかわかってないんじゃないのか？
O/Rマッパーなんか関係ないだろ。
IN句は普通に使える。
0040nobodyさん
2016/10/18(火) 16:42:03.97ID:???>>前スレ764
> しかし現実にPDOはIN句が使えなかったりして
いや、使える。
> そういうことを考えると入れる時にエスケープしておくのが安全かと自分は考えている
SQLインジェクションの可能性があるなら、プリペアードクエリを使えば良い。IN句でも使える。
>>前スレ788
> IN句のやつをorでやればできるけど
この文章で、本当に使えないんだと思い込んでいることがわかるな。
なお、PostgreSQLの場合、プリペアードクエリを使った場合のデータベースサーバプロセスとPHPプロセスの通信回数は、パラメータの個数によらない。
複数のパラメータが1回で送信される。なので、プロセス間通信のパフーマンスにはパラメータの個数はほぼ影響しない。
0041nobodyさん
2016/10/18(火) 16:50:15.88ID:???> 「出来るだけ簡単にクエリビルドできること」
> 「場合によってはクエリの生成をプログラマに委ねるる事が出来る事」
> の二つだ。
O/RM = クエリビルダ であるかのような認識をしているのかねぇ。
0042nobodyさん
2016/10/18(火) 17:44:07.55ID:???クラス群だ
そのクラス内のメソッドなりの標準装備されている機能のみでIN句は使用できないよね？という意図ね
前スレとかのことは今は話していないので忘れて良いよ
そんなのスクリプトで色々やったらPHPで大抵のことはできるだろ
拡大解釈だよ
0043nobodyさん
2016/10/18(火) 17:49:54.10ID:???いや、普通に使えるのだが。
$stmt = $pdo->prepare('select * from user where user_id in (?, ?, ?)');
$stmt->execute(['user1', 'user2', 'user3']);
$rows = $stmt->fetchAll();
どこが使用できないのだ？
0044nobodyさん
2016/10/18(火) 17:55:17.63ID:???それにINを使用するケースって数が膨大だったり使用するプレースホルダの数が未確定だったりすることが多いでしょ
そういう場合に標準のメソッドでは使用できない
0045nobodyさん
2016/10/18(火) 17:58:48.08ID:???> ?のプレースホルダ―は今あまり使用しないからね
それ、IN句が使えるかどうかと関係ないな。
> それにINを使用するケースって数が膨大だったり
膨大になることなんてめったにないが、なったとしてもIN句はつかえるし。
> 使用するプレースホルダの数が未確定だったりすることが多いでしょ
未確定なことなんてありえない。未確定だったらexecute()にパラメータ渡せないし。
> そういう場合に標準のメソッドでは使用できない
いや、できてるでしょ。
0046nobodyさん
2016/10/18(火) 18:03:06.13ID:???select id from foo => 1000行くらいデータ取得
select * from bar where foo_id in (1000個くらいの値リスト)
とかやってるんじゃないだろうな。
0047nobodyさん
2016/10/18(火) 18:18:28.19ID:???JOINってINNER JOINやOUTER JOIN、サブクエリとかの結合のことか？
それなら使いまくってるが
0048nobodyさん
2016/10/18(火) 18:23:24.68ID:???0049nobodyさん
2016/10/18(火) 18:30:49.42ID:???PDOのプリペアドステートメントはデータベースのプリペアドステートメントに1対1で対応しているべきもので, IN句内のプレースホルダ数の異なるSQLは同一のプリペアドステートメントにならない以上はarrayのバインド可能なプリペアドステートメントはPDOとしてはあり得ない。
だからarrayをバインドしたいと主張するならそれはクエリビルダの役割であって, SQLを抽象化しないPDOが行えてはおかしいことだ。
0050nobodyさん
2016/10/18(火) 18:32:57.00ID:???↓
他: プリペアードクエリ使えよ
↓
A: PDOだとIN句が使えないじゃん
↓
他: いや使えるでしょ
という流れ。
あと、
> PDOでプレースホルダも使ってるけど
> 念には念を入れて
エスケープもするとか発言してる。
O''reillyになっちゃうじゃん。
0052nobodyさん
2016/10/18(火) 18:53:15.51ID:???そしてそれを IN が使えないという話にしてはいけないということ。
それ以外の話で IN が使えないというのなら、使えないって人からの追加説明が必要かなと。
0053nobodyさん
2016/10/18(火) 18:54:24.93ID:???$stmt->bindValue(':query', 'select * from foo where bar="baz"', PDO::PARAM_STR);
これがバインド出来ねーって言ってるようなもんだろ
0055nobodyさん
2016/10/18(火) 22:51:36.87ID:???{
foreach($b as $value).... // bを配列として変換済み
}
上の関数を呼び出す時に、下記のようにbをarrayでもintでも可能にしたいです。
testfunc(a, [1,2,3]);
testfunc(a, 1);
どういう風に関数実装すればよいでしょうか
0056nobodyさん
2016/10/18(火) 23:48:00.25ID:???bを配列として何らかの変換を行っているのであれば
条件分けでもいけるのでは？
もしくは引数を配列にするとか
0058nobodyさん
2016/10/19(水) 00:05:25.02ID:???無理筋じゃーねーよ。他の言語のデータベース接続インターフェースとかじゃ割と出来るし、PDOを拡張するだけで一応は実装可能なんだから。
PDOが名前付きプレースホルダ自体に配列が使えないっつーワンサイドハンドドロップダウン仕様なのが問題なんじゃ。
0059nobodyさん
2016/10/19(水) 00:18:28.66ID:???>>49を読んで, その上でそう思うということなのか？
あと, SQLを抽象化しないDBALで"出来る"例を挙げてくれ
0060nobodyさん
2016/10/19(水) 00:28:41.03ID:???知らんけど、同じくDBALを謳う「PDOを拡張したクラス」が山のようにある(そしてそいつらは配列をバインドできる)のはどういうことや？
PDOはRDBMSの種類毎の違いを抽象化してくれてるまではええんやが、プリペアードステートメントのパラメータのバインド部分が貧弱なんだよ。だからみんな拡張するんだ。
ドキュメントにも書いてある通り、「端的に言えば文字列置換してるだけやで」って位だからな。気が利かない。
0061nobodyさん
2016/10/19(水) 00:29:17.31ID:???0062nobodyさん
2016/10/19(水) 00:29:57.71ID:???0063nobodyさん
2016/10/19(水) 00:31:09.84ID:???0064nobodyさん
2016/10/19(水) 00:33:33.91ID:???つうかみんなそこら辺に不満言いながら拡張PDO書くのがphpおじさんたちの仕事だよ。
もっと言うならexecuteした後にfetchさせるのとかもクッソ面倒いから大体そこも拡張っつーかラップするよ。
0065nobodyさん
2016/10/19(水) 00:40:40.11ID:???プリペアドステートメントのバインドが文字列置換だけなわけがない
通常のいわゆる静的プレースホルダではDB側が用意した(PREPARE文で発行した)ステートメントにUSING句でバインドして実行している
DB側でこの機構に対応していない場合(や利用しようとして失敗した場合(今はどうか知らない))にはエミュレーション(いわゆる動的プレースホルダ)としてPHP側が処理を代替する
静的プレースホルダの機能はDB側機能で制約を受ける
PDOは"SQLを抽象化しない""DBへの接続とクエリのみを抽象化する"DBALである以上, SQLを弄らねばならない機能はより上位のレイヤで実装されなければならない
006665
2016/10/19(水) 00:43:28.22ID:???0067nobodyさん
2016/10/19(水) 00:56:34.77ID:???つうても静的プレースホルダに配列を突っ込めるRDBMSは多分存在するよな？
なんで、in句にプレースホルダを入れてそこに配列バインド出来ないのはやっぱりPDO側の怠慢やと思うんや。
エミュモード有効なら結局SQL組み直すやん。
なら配列入れて無効なら展開するような仕様でええ思うんだけどな。(まあ、その仕様入れるとSQL自体がバグる可能性もあるので一長一短だが)
006865
2016/10/19(水) 01:07:02.59ID:???> つうても静的プレースホルダに配列を突っ込めるRDBMSは多分存在するよな？
知る限りないが, ご存知なら挙げてくれ
> エミュモード有効なら結局SQL組み直すやん
プリペアドステートメントが利用可能かどうか結果が変わる仕様はまともではない
少なくともプリペアドステートメントという以上はDBのそれと1対1であるように実装されるべきだし, そうなっている
何度も言うようだけどもその枠から外れるならそれはPDOが目指すものではない
0069nobodyさん
2016/10/19(水) 01:15:52.87ID:???ワイも詳しくないけど、なんかオラクル辺りは配列バインド出来るらしいよ。ODP.netにはそういう機能があるらしい。
それがSQLを破壊してるかどうかまでは分からんけど。
007065
2016/10/19(水) 01:19:10.84ID:???その「配列をバインド出来る」の意味は :array というプレースホルダにARRAY型の値をそのまま置き換えるということだろう
決して :array にバインドするARRAY型変数の中身が展開されて並ぶわけではない
ましてやIN句には括弧が必須なのだから IN :array みたいな書き方をすればコンパイルエラーだ
0071nobodyさん
2016/10/19(水) 01:25:15.44ID:???何言ってるか微妙に分からんが、SQL上で
in(1,2,3,4,5)みたいになっているのは、php上で[1,2,3,4,5]になってるのとは等価だろ。
データの内部形式に違いはあれど配列を扱っていること自体に違いはない。
その配列形式のデータをDB側が受け取れるかどうかじゃねえか。
もっと具体的に言うとmysqlにはSET型もenum型もあるんやから、コレをPDO側で吸収する事は本来は出来るハズやで。postgresにはpolygonとかもあるやん。
ここら辺のデータを受け渡すインターフェースがあってもおかしかないとは思うんやがのう。
0073nobodyさん
2016/10/19(水) 01:30:23.68ID:???0075nobodyさん
2016/10/19(水) 02:23:17.81ID:???IN文の中身に関してはそうだけど、values()の中身とかは実質配列型だろ。
だから配列をぶっこむプリペアードステートメントが存在しても全然おかしくないしmysqlはSET型ぶち込めるし。
やっぱPDOが手を抜いてる説がワイの中で根強いなあ。
0076nobodyさん
2016/10/19(水) 02:27:05.66ID:???0077nobodyさん
2016/10/19(水) 02:28:37.37ID:???プリペアードステートメントだから配列は使えないなんてのはすげえ雑な扱いに思うけどね。
いくらPDOがネイティブ寄りの思想だからって出来ないこと多すぎなんやが。
0078nobodyさん
2016/10/19(水) 02:32:17.19ID:???実質配列型というが, SQLのARRAY型の要素は全て同じ型だ
「だから配列をぶっこむプリペアードステートメントが存在しても全然おかしくない」というのもSQL文との整合性が保たれない(IN句で IN :array は認められない)以上はプリペアドステートメント「のようなもの」ではあってもそのものではない
まるでPDOに特有の問題かのように言うが, 理想的, 或いはPDOよりマシだという実装の具体例を(別の言語でも結構だが)挙げてくれないと比較のしようもない
0079nobodyさん
2016/10/19(水) 02:32:28.64ID:???$st->bind(":in","SELECT 1,2,3")とかやればいいような気がしてきたな。
それもそれで面倒な気もするが。
0080nobodyさん
2016/10/19(水) 02:49:33.98ID:???回答はやはりPDOより上のレイヤーでやるべきだと
https://bugs.php.net/bug.php?id=64852
0081nobodyさん
2016/10/19(水) 02:53:25.31ID:???INは実行前に数がわからない。だから「何なら入れていいか」がわからない。
が、values()とかは数も型もわかる。
数と型が分かるなら、それこそ文字列と同じ扱いにできるやな。
実際にJavaのPreparedStatementクラスにはSetArray()ってメソッドがあるらしいぞ。
使ったことないからどれくらい使えるかわからんが。
0082nobodyさん
2016/10/19(水) 03:02:36.73ID:???> 数と型が分かるなら、それこそ文字列と同じ扱いにできるやな。
VALUES(?, ?, ?)などとしてPHP配列を要素を適切に並べてバインドすればよいとういことか？
最早元の話題から大きく外れているが, どういうAPIで実装すべきと考えているのか
JavaのSetArrayは正しくSQL文中のプレースホルダをARRAY型の値で置き換える
相当するものはPDOにはないからあってもよいとは思うが, IN句やVALUESで指摘された問題の解決にはなっていない(その目的には使えない)
0083nobodyさん
2016/10/19(水) 03:09:34.66ID:???0084nobodyさん
2016/10/19(水) 03:21:09.25ID:???>ここら辺のデータを受け渡すインターフェースがあってもおかしかないとは思うんやがのう。
PDOにしろADO.NETにしろJDBC、ODBC、ADO,OLEDBにしろ、基本はデータベースをベンダによらず
抽象的に扱えるインタフェースを提供するのが目的なんだから、特定のデータベースの特定の
型向けのインターフェースなんて用意しないだろ。
0085nobodyさん
2016/10/19(水) 03:27:06.04ID:???TEXTだったりvarcharだったりをSTRINGに抽象化する程度には纏められるやろ。SET型もpolygon型も実態は固定長の配列やし。それこそarrayで一纏めに出来るはずやで。
0086nobodyさん
2016/10/19(水) 03:27:34.58ID:???具体的に例あげろよ。
0087nobodyさん
2016/10/19(水) 03:29:00.07ID:???そういうのはもう設計してる人に言おうぜ。俺らに
何度言ったって無駄だろ？？
それともただのかまってちゃんなの？
0088nobodyさん
2016/10/19(水) 03:30:26.87ID:???0089nobodyさん
2016/10/19(水) 03:30:40.03ID:???ただのかまってちゃんレベルになってきてるぞ。
0092nobodyさん
2016/10/19(水) 03:48:00.91ID:???クエリビルダじゃなくてデータベース接続インターフェースって自分で言ってないか？
話が変わってねぇ？
0093nobodyさん
2016/10/19(水) 04:51:13.91ID:???0094nobodyさん
2016/10/19(水) 06:22:40.53ID:???foreachで楽に組み立てられるだろ
0096nobodyさん
2016/10/19(水) 10:30:47.12ID:???PostgreSQLだと、INの方が速いけどね。
10万件の中から10件を検索（indexが使われる検索）
INを使った場合:
https://explain.depesz.com/s/PpNF
Planning time: 0.141 ms
Execution time: 0.177 ms
ORを使った場合:
https://explain.depesz.com/s/iORg
Planning time: 0.281 ms
Execution time: 0.469 ms
0097nobodyさん
2016/10/19(水) 10:31:49.79ID:???0098nobodyさん
2016/10/19(水) 10:43:30.73ID:???日本在住じゃないのか？
■ このスレッドは過去ログ倉庫に格納されています