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の改造
0175nobodyさん
2016/10/19(水) 21:41:47.75ID:???途方に暮れかけた
> ちゃうわ。
期待したけど、期待するだけ無駄だった。
なぜそのような強気でいられるのか
0176nobodyさん
2016/10/19(水) 21:45:35.82ID:???俺の他にも有益なレスをしてくれてる人もいるのに、全部ひっくるめて無駄にしてる
0177nobodyさん
2016/10/19(水) 21:48:57.36ID:???無駄ちゃうで。考えたプロセスがこうして出力されてることは結構有益やよ。他の人間も辿れるからな。
0178nobodyさん
2016/10/19(水) 21:48:58.52ID:???0179nobodyさん
2016/10/19(水) 21:50:43.03ID:???せやかて言われたままに事実を受け止めてもーたら、それは検証という作業を省くオカルトっちゅー奴になってまうやで。
先ずは仮説から。コレは基本やで。
0180nobodyさん
2016/10/19(水) 21:52:07.18ID:???* PDOの目的に従えば現状のバインド機構は適切
* PDOの目的を変更する必要を感じない
* PDOより上のレイヤのライブラリを公式で作成してくれるなら有り難い
* 但し実用上DoctrineやEloquentで十分なので積極的に後押しはしない
0182nobodyさん
2016/10/19(水) 21:56:01.17ID:???PDOがDB標準を目標としているならarrayはバインド出来て然るべしやから、ワイはPDOの目的はまだ未達と見るで。
0183nobodyさん
2016/10/19(水) 21:57:59.21ID:???地球の端っこに行ってなお「地面は平らでござるよ」って仮説が出てくるかよ。
仮説は勘とイマジネーションから出ちゃっていいんだよ。
0184nobodyさん
2016/10/19(水) 21:58:14.71ID:???そこは認めるよ, Arrayはバインド出来ても良い
しかしそれはIN句やVALUES句の問題を解決しない
0185nobodyさん
2016/10/19(水) 21:58:26.68ID:???その話と IN (?) に [1, 2, 3] をバインドしたら IN (1, 2, 3) になる(なってほしい)という話は別だということは理解できたの？
0186nobodyさん
2016/10/19(水) 22:08:36.54ID:???多分arrayがバインド出来るならarrayを展開する関数も実装されると思うから、そこがPDO標準で存在しないとしても目的達成には充分。
inの中のarrayがどういう動きになるかは仕様の話やしな。
0187nobodyさん
2016/10/19(水) 22:10:41.91ID:???> arrayを展開する関数
ARRAY型をどういう型に展開するのか？
そもそもIN (a, b, c)の (a, b, c) という組が何かの型だとお考えか？
0188nobodyさん
2016/10/19(水) 22:13:19.36ID:???配列型について調べてるのかと思ったらまた思い込みで話をしちゃってる
0189nobodyさん
2016/10/19(水) 22:14:37.10ID:???RDBMSによってはarray_to_string()やその逆のgroup_concat()がある。(いや同じか？)postgresでは集合を返すgenerate_group()関数もあるよな。
だからそっから先はDBごとの仕様に依存することにはなるだろうけど、システム開発的な用途であればそれで十分使える。
0193nobodyさん
2016/10/19(水) 22:18:52.60ID:???仮に配列を複数の文字列にするなら、それはそれで検索条件としては使えるで。比較する方を文字列にしちまえばええんやから。
0196nobodyさん
2016/10/19(水) 22:22:26.11ID:???いや、in(:array)に[1,2,3]を渡して内部的にin('1','2','3')になるなら左の値をキャストすりゃええねんってこった。
0197nobodyさん
2016/10/19(水) 22:26:04.75ID:???>IN (?) に [1, 2, 3] をバインドしたら IN (1, 2, 3) になる(なってほしい)
みたいなのさ、
プリペアドステートメント使った問い合わせが、どうやってRDBに渡されるか分かって「そうなって欲しい」って言ってるの？
（否、分かっているはずがなかろう）
一応、PDOのエミュレーション使うならそうすることは可能だろうが、
SQLiteみたいなRDB側でプリペアドに対応していないDBでもなければ
エミュレーションなんか使わないほうが良い事はわかりきってるだろ。
エミュレーションしないでプリペアド使った問い合わせして、
>IN (?) に [1, 2, 3] をバインドしたら IN (1, 2, 3) になる(なってほしい)
そんな都合のいいbindが出来るわけねーだろ。
つまりそれはPDOのすべき仕事じゃねーって事だろーが。
プリペアードステートメントって何だかわかってんのかよ？ 本当に脳みそあんのかよ？
>PDOがDB標準を目標としているならarrayはバインド出来て然るべしやから、ワイはPDOの目的はまだ未達と見るで。
>>180を100回読んでから本当にくたばれ、クソエセ関西弁。
0198nobodyさん
2016/10/19(水) 22:27:47.53ID:???多分listagg関数を使って左右入れ替えてlike文にすれば一応イケるはず。
パズルSQLの領域だけどなw
0199nobodyさん
2016/10/19(水) 22:30:01.78ID:???調べて分かったけど、oracleは普通にその構文通るらしいぞ。その目的通りのinになるくさい。
オプションとかもあって標準ではないのかもしれんが。
0200nobodyさん
2016/10/19(水) 22:31:58.54ID:???0201nobodyさん
2016/10/19(水) 22:34:25.19ID:???group_concat(:array,デリミタ) like 左カラム
ってすればいい。下手したら普通にinするより速くなるかもな。
0202nobodyさん
2016/10/19(水) 22:35:38.11ID:???だから、仮説の状態で置いておけばその内環境持ってる奴が真偽を確かめてくれるだろ？
そーいうこっちゃで。
0204nobodyさん
2016/10/19(水) 22:42:11.21ID:???おめーは上でもarrayの誤読してる前科あるんだから
「くさい」とかほざいてねーでソース出せ。
普通に考えて、そんなことしたらプリペアドの意味がなくなるか、オプティマイザが複雑怪奇になる。
0206nobodyさん
2016/10/19(水) 22:50:19.24ID:???0207nobodyさん
2016/10/19(水) 22:56:53.79ID:???多分目的がすれ違ってるから自分の意見を言っておくけど、「値の数がが不定なものをバインドすることはよくあるからそれが出来ればいい。inで使えると便利」であって、inの構文になるかどうかは割とどうでも良い。SQLの中に配列入れて判定文書けるならそれで正義や。
0208nobodyさん
2016/10/19(水) 22:59:06.03ID:???配列型がbindできるならそれこそ IN でどうにかなんて発想には決してならないので、一旦マニュアル見直してみて。
その上で>>153をもっかい読み直してみて。
0209nobodyさん
2016/10/19(水) 23:03:15.97ID:???よく分からんけど、他に優先度が高そうな致命的なアンダー仕様が存在するんけ？
パッと思いつくようなのは直ぐには出てこないけど、なんかあったっけ。
0211nobodyさん
2016/10/19(水) 23:07:02.24ID:???> 直ぐには出てこない
0212nobodyさん
2016/10/19(水) 23:07:03.80ID:???真面目に、抽象的過ぎるのか、ワイが知らんDBの基礎仕様的なものがあるのか、それともタダのハッタリなのかの区別が付かない。
ヒントをくれとは言わないが、区別出来るようには出来るやろか？
0213nobodyさん
2016/10/19(水) 23:07:56.14ID:???0214nobodyさん
2016/10/19(水) 23:08:28.74ID:???やってるよ。
でも色々調べたら「PDOでも出来ておかしくない」って方向に自分の考えが固まりつつあるんや。
0216nobodyさん
2016/10/19(水) 23:09:34.16ID:???IN (a, b, c) の(a, b, c)は一般に「配列型」の値ではない, というかそもそも型を持った値ではない
SQLの構文要素 () にaとbとcが並べて書かれているだけ
0217nobodyさん
2016/10/19(水) 23:11:51.23ID:???ワイはさっきから「配列を値のリストに変換出来ればええ」ゆうとるが。そしてそれはちょい変なやり方やが出来るやろ。
0221nobodyさん
2016/10/19(水) 23:15:13.62ID:???0223nobodyさん
2016/10/19(水) 23:27:07.20ID:???仮想コードだがこういうこと。
データ[1,2,3]が:arrayに渡されるとする。
実行したいSQL文は
SELECT * FROM T WHERE ID IN (:array);
これをGROUP_CONCAT()で代わりにやるには、
SELECT * FROM T WHERE GROUP_CONCAT(:array,'-') REGEX ID;
ってする。そうすると、仮にTテーブルに「1,3,5,7,9」って順にデータが入ってたとしたら
比較対象 検索ID 比較結果
1-2-3 1 true
1-2-3 3 true
1-2-3 5 false
みたいになって、ID1と3のレコードだけ取り出せる訳だが。
0224nobodyさん
2016/10/19(水) 23:29:37.60ID:???<値1>,<値2> みたいにエスケープをかけて、REGEXの方にも <>を足してやればいい。
何事も工夫です。
0225nobodyさん
2016/10/19(水) 23:36:58.74ID:???0226nobodyさん
2016/10/19(水) 23:39:13.00ID:???SELECT * FROM T WHERE ID IN (:array)
の形のプリペアドステートメントの発行を求めているのに違う形のステートメントを発行するのがまともな実装か？
それが適切な例だと考えているなら話は最初にループするぞ
* PDOはSQLを極力書き換えない
* PDOはDBに委任出来る処理はそのまま委任する
上の前提は当然だと思っていたが, 明記する必要がある？
0227nobodyさん
2016/10/19(水) 23:40:45.74ID:???arrayがarrayとしてbindされる前提だよね？
そしてそれならそんな小細工する必要なんてなくなる。
0231nobodyさん
2016/10/19(水) 23:43:55.34ID:???IN (:array) の :array に $array = [1, 2, 3] をARRAY型としてバインド出来ても動かないでしょ
IN :array ならバインド以前にコンパイル出来ないでしょ
0232nobodyさん
2016/10/19(水) 23:44:44.61ID:???SQLを書くのは人間だよ。「不定の値をバインドしたい」だけが達成できれば要件満たすコードがすげー書きやすくなるって話さね。
PDOがarrayをバインドできるようになればこういったブレイクスルーが起こせるんや。
0233nobodyさん
2016/10/19(水) 23:46:44.22ID:???もちろんそれは動かない、ので、それをどうにかしましょうというのが >>153 で書いた「あさってのこと」で
配列型に対応するのは「前にしないといけないこと」。
で、それ(配列型に対応)がされた前提であるならそもそも IN 使う必要なんてなくなるよという話ですよ。
0234nobodyさん
2016/10/19(水) 23:46:55.79ID:???それならPDOじゃなくてilluminate/databaseのQueryBuilderでも使えば宜しい
0235nobodyさん
2016/10/19(水) 23:47:56.61ID:???arrayがバインドできてもin(:array)だとArray型を比較しようとする仕様だった場合の話をしている。
その場合は今ある関数でなんとかするならこういう小細工になるし、
配列をxargsみたいに解釈してくれる関数が出てくるのならそれを使えばいい。
いづれにしても「できる」ってことやな。
0239nobodyさん
2016/10/19(水) 23:56:24.40ID:???「PDOはSQLを書き換えない」んだろ？
ORMやらクエリビルダやらのPHPと一体となっているSQLではなく、
クエリ文とパラメータだけで編成された、割とピュアなデータ入出力設計ができるようになる訳だ。
結構メリットっちゃメリットだよ。システムがPHPに引きずられなくなる訳だし。
0240nobodyさん
2016/10/20(木) 00:00:08.32ID:???一旦まとめさせてほしいんだけどさ、配列型がbindできるようになったらさ、スッキリするよね。
で、
>IN (?) に [1, 2, 3] をバインドしたら IN (1, 2, 3) になる(なってほしい)
なんて願望はもうなくなるよね。
0241nobodyさん
2016/10/20(木) 00:02:27.96ID:???0242nobodyさん
2016/10/20(木) 00:03:04.90ID:???> SELECT * FROM T WHERE GROUP_CONCAT(:array,'-') REGEX ID;
(とてもスマートではないけれど)こう書けばいいわけだから、 IN (1, 2, 3) になってほしいって願望はもうないよね。
0243nobodyさん
2016/10/20(木) 00:05:45.33ID:???それもよう分からん。配列型が使えるとIN()文が他のものでだいたいできるような話にはならんと思うのやが。
少なからず配列型を使えるようになったらIN(配列)の出番はかなり増すと思うんだが。
>>241
SQL99ではARRAYは型なんだってよ！
0244nobodyさん
2016/10/20(木) 00:08:41.04ID:???ARRAYは型らしいから、通常のロジックで言えばIN(:array)は配列型と配列型比較することになる。
それを回避するためのコードがGROUP_CONCAT()で、SQLパズル的なコードだから「なるべく使いたくない」。
INで動くならINで書くよ。IN(XARGS(:array))でいいならそうするよ。
0246nobodyさん
2016/10/20(木) 00:11:02.88ID:???DB側でSQLパズルしなければならない(例のXARGSのようなものは存在しない)から>>240,242何だと思うけど
0247nobodyさん
2016/10/20(木) 00:15:43.84ID:???もしSQLパズルでしか動かないとしても、クエリビルダを使用しないという選択肢を取れることは結構メリットではある。
基幹系とかデータの寿命が半世紀以上になるような部門だと割とマジで福音になるんじゃないだろうか。
（まあ、そういうところこそもっとスマートではない泥臭いやり方してるもんだけど）
0248nobodyさん
2016/10/20(木) 00:17:54.15ID:???つまり
>>240
> >IN (?) に [1, 2, 3] をバインドしたら IN (1, 2, 3) になる(なってほしい)
> なんて願望はもうなくなるよね。
ということでよろしいか？
arrayがバインド出来てよいことには同意しておくから。
0250nobodyさん
2016/10/20(木) 00:31:18.04ID:???0252nobodyさん
2016/10/20(木) 00:45:45.25ID:???これだと多分文字列のふりしてJsonデータ入れれば配列を入れたことと同じになるくさいから、
もうほとんど目的達成されてるのかも。PDOに頼らずとも。
0254nobodyさん
2016/10/20(木) 01:04:00.18ID:???0256nobodyさん
2016/10/20(木) 01:12:49.83ID:???SET型は64個までしか値持てへんねん。つうことは必然と種類フラグ的な用途でしか使えへんねん。
特定のユーザIDの配列とか渡せないから実質使えへんで。
まあでもJSON実装したんならArrayもそのうち実装されるやろ。
0257nobodyさん
2016/10/20(木) 03:08:40.95ID:???Arrayも、代わりになるデータ型も無いことを知っている上で >>251 を書いたの？
それならPDOよりも先にMySQLに…って>>254が正解だったか。
0258nobodyさん
2016/10/20(木) 07:08:33.92ID:???pdo+mysqlのデフォルト動作ってエミュモードなんねや。
そもそもパフォーマンスを必要とされるmysqlでいちいち複数ステートメントになるネイティヴプリペアードステートメント打つ必要は無いねん。
だから、別にmysqlにarrayが実装されてるかどうかはあんま関係ないねん。
PDOで内部的に書き換えてくれりゃええんやから。
0260nobodyさん
2016/10/20(木) 14:17:15.32ID:???なんでエミュレート切った方がいいのかもわかってないし、
プリペアする理由はSQLインジェクション対策くらいにしか思ってないし、
もう、この関西弁、どうしようもねーよ。
0261nobodyさん
2016/10/20(木) 15:52:42.51ID:???普通じゃない。サルカニの人と同じく、他人と仕事をしないで自分の世界に閉じこもっていてほしい。
0262nobodyさん
2016/10/20(木) 16:36:20.83ID:???ワイの知る限りではmySQLでエミュレーションモードを切る利点もデメリットも無い。
なんか具体的に問題となることあんのか？
「PDOはクエリを改変しない」原理主義的なアレか？
0263nobodyさん
2016/10/20(木) 17:14:39.56ID:???この辺じゃないの？
http://unskilled.site/%E3%81%AA%E3%82%93%E3%81%A7php%E3%81%AFmysql%E3%81%8B%E3%82%89%E3%81%AE%E3%83%AA%E3%82%B6%E3%83%AB%E3%83%88%E3%81%8Cint%E5%9E%8B%E3%81%AE%E3%81%AF%E3%81%9A%E3%81%AA%E3%81%AE%E3%81%ABstring%E5%9E%8B/
0264nobodyさん
2016/10/21(金) 14:50:33.94ID:???0265nobodyさん
2016/10/21(金) 16:56:20.63ID:???>ワイの知る限りではmySQLでエミュレーションモードを切る利点もデメリットも無い。
複文。
くたばれ、クソ関西弁。
0266nobodyさん
2016/10/21(金) 18:13:21.18ID:???数値項目も文字列が戻る前提でコーディングし、なおかつPHPでもJavaScriptでも律儀に"==="を使っていて、ある日数値項目は数値で戻るようになると死ぬ
0267nobodyさん
2016/10/21(金) 18:35:28.79ID:???そんなんで死なないようにO/Rマッパーを作ってラップし、
エンティティの定義で型強制をするわけだが、
>>141の言ってるEloquentもDoctrineって、その辺やってくれるのかね？
俺は昔Doctrineの導入のクソめんどくささに辟易して自分で[クエリビルダ：O/Rマッパー]を作るに至った。
composerとか、まだ普及してなかった時代の話だ。
今はもっとマシかもしれん。
0268nobodyさん
2016/10/21(金) 18:37:53.01ID:???よく考えてみるべきだよ。
0269nobodyさん
2016/10/21(金) 22:03:34.73ID:???pearみたいなもんじゃないの？
0270nobodyさん
2016/10/21(金) 23:23:47.03ID:???とりあえず使ってみれば分かるけど, 依存関係の管理をしてくれる
そしてオートローダ―も自動生成してくれるからプログラマの手間が大幅に減る
Rubyのgem/bundler, Pythonのpip, Node.jsのnpmみたいな。最早必須
0271nobodyさん
2016/10/22(土) 01:21:32.24ID:???ボタンを押したとき、非同期でdata.phpからデータを取得しています。
ページの初期化時もdata.phpからデータを取得するにはどうすればよいでしょうか。
0272nobodyさん
2016/10/22(土) 05:48:24.63ID:???ていうかそれPHPの質問じゃないで
0274272
2016/10/22(土) 06:29:08.38ID:???あ・・初期化ってonload時のことかと思ってそう答えたけど
phpだけですませたいってことか？
home.phpで
・data.phpをrequireして関数を呼ぶ
・ボタン押した時と同じ内容のリクエストをdata.phpに送って結果を取得する
（curlあるいはstream_context作成してfile_get_contentsなど)
とかそのあたり？中身わからんのでなんとも
■ このスレッドは過去ログ倉庫に格納されています