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の改造
0102nobodyさん
2016/10/19(水) 14:06:53.65ID:???安全のためにね
↓
プリペアードクエリ使え
↓
IN句じゃつかえないだろ
↓
いや使えるし
↓
でもコードを少し書かないと使えないだろ
その意味で使えないと言ったんだよ
そもそもIN句遅いし、OR使えよ
↓
いやIN句の方が速いし
↓
今ココ
0103nobodyさん
2016/10/19(水) 14:14:37.64ID:???PDOはDBへの接続を抽象化するためのものでSQLを抽象化するためのものではない
なぜ全てをPDOに要求するのか？
0104nobodyさん
2016/10/19(水) 14:18:54.42ID:???{
$array = [];
foreach ($variable as $value) {
$array[$value] => [1,2,3];
}
return $array;
}
こういうのって最初に
$array = [];
で初期化する必要ないのかな？
削除するかで迷ってる
0105nobodyさん
2016/10/19(水) 14:19:11.56ID:???0108nobodyさん
2016/10/19(水) 14:37:40.79ID:???> 俺は多分カニ味噌？と言われた人間だが別の人とやり合ってたようだなｗ
かに味噌がどうこうという流れは無視してたが、最近の流れを追うとそう言われるのも妥当かなと思ったりw
0110nobodyさん
2016/10/19(水) 15:52:44.73ID:???PHPを主体にしてやってるんでしょうか？
0111nobodyさん
2016/10/19(水) 17:11:58.32ID:???0112nobodyさん
2016/10/19(水) 17:12:37.66ID:???0113nobodyさん
2016/10/19(水) 17:17:09.08ID:???柔軟にいろいろ吸収できれば何とかなると思うけど。
0115nobodyさん
2016/10/19(水) 17:25:51.43ID:???0116nobodyさん
2016/10/19(水) 17:34:13.99ID:???> だから配列をぶっこむプリペアードステートメントが存在しても全然おかしくないし
これには同意
$stmt = $pdo->prepare('select * from user where created between ? and ? and status in (?)');
$stmt->execute([$from, $to, ['hoge', 'fuga']]);
って書かしてくれてもばちはあたらんと思うぞ
0118nobodyさん
2016/10/19(水) 18:07:48.96ID:???arrayBind
arrayExecute
とかね
0119nobodyさん
2016/10/19(水) 18:18:24.40ID:???問題ない。
$sql = 'insert into books (tilte, authors) values (?, array[?])';
$stmt->execute(['php is sucks', ['matz', 'larry']);
$array = ['matz', 'larry'];
$stmt->execute(['rtfm', $array]);
0120119
2016/10/19(水) 18:20:48.34ID:???0121nobodyさん
2016/10/19(水) 18:51:55.67ID:???phpはあくまでサーバサイドのコードやからコンマ何秒を求められる事はこれから先も無いよ。
マキシマム数秒は大前提だけど、マキシマム何秒に抑えるのはphpとかの言語を駆使する話ではない。
システム構成とそのアプリケーションの仕様との相談だね。
0122nobodyさん
2016/10/19(水) 18:52:03.03ID:???0123nobodyさん
2016/10/19(水) 18:55:43.49ID:???PDOより上の機能をphp標準が用意してくれないからだろ……
だから名前も分からぬ機能もインターフェースも雑多なr/oマッパーが蔓延るんやないかい。
ワイらはORMなんか別に使う気はなく、クエリを安全にエスケープできればええゆうのに。
0124nobodyさん
2016/10/19(水) 18:56:11.91ID:???そんなもんしかないからな
0127nobodyさん
2016/10/19(水) 19:18:34.73ID:???0128nobodyさん
2016/10/19(水) 19:45:08.74ID:???いくつものjoinによっては可読性を落とし
MySQLのバージョンを理由に、謎のselect連発
だから、PDOなり、ORMなり、クエリービルダーなり、きちんと設計されて
使用されているところのほうが珍しい
0129nobodyさん
2016/10/19(水) 19:46:10.18ID:???実際にPDOを継承したり内包してるDBライブラリが数数え切れない程度にあるこの状況を見てどう思うね。
もうちょい統一してほしい思うやろ。
0131nobodyさん
2016/10/19(水) 19:50:13.31ID:???PDOに持たせなくてもいいから、PDOより上でORMより下くらいの扱いやすいDB操作インターフェース作れや。
今のopenGL直に叩いてるような状況が正しい訳ねえやろ。
0132nobodyさん
2016/10/19(水) 19:50:14.37ID:???0133nobodyさん
2016/10/19(水) 20:15:41.19ID:???一体どんな言語が, 言語の規格に存在しないにも拘らずDB接続の抽象化を超えるような機能をその言語ベンダ自身で提供しているんだ？
その機能を提供するための標準的なAPIの規格でも存在しているのか？
クエリをどうこうしたいなら単にクエリビルダだけを使えばよい(illuminate/databaseのQueryBuilderだけでも使える)
大体ORMレベルまで行ってしまったらActiveRecordとDataModelみたいな設計方針の違いもあるんだから多様性はあって当然
言語ベンダとしては最低限, DBへの接続を抽象化する, その目的はPDOで適切に達成されている
0134nobodyさん
2016/10/19(水) 20:21:05.62ID:???APIは提供したからあとは描画するだけだよ、頑張ってね的なほっぽり投げ具合だから嫌だっつってんだろ。
openGLやってバージョン上がるごとにどんどん抽象化レベル高くなってんねんで。
PDOがそこやってもええやろ。
そもそもプリペアードクエリの?文字も:文字もDBの仕様じゃないのをPDOが拡大解釈しとる話やん。
もっと制御文字増やして拡大解釈しまくるくらいは出来るやろ？
0135nobodyさん
2016/10/19(水) 20:26:01.53ID:???0137nobodyさん
2016/10/19(水) 20:27:48.58ID:???0138nobodyさん
2016/10/19(水) 20:28:15.02ID:???0139nobodyさん
2016/10/19(水) 20:30:38.82ID:???ああ言えばこう言う、でもでもだって
0140nobodyさん
2016/10/19(水) 20:31:18.78ID:???0141nobodyさん
2016/10/19(水) 20:31:29.20ID:???そういうご要望はPHPの公式メーリングリストにでも投げられたら如何か
EloquentもDoctrineもある現状, どの程度合意を得られるかは分からんが, 納得させるのが上手いプレゼンターだ
0142nobodyさん
2016/10/19(水) 20:33:09.84ID:???と思うじゃん？ sqliteとか普通にプリペアードステートメントの機能が無いDBもあるじゃん？
そういうRDBMSからすればクエリを破壊してる事にはなってるわけじゃん？
0144nobodyさん
2016/10/19(水) 20:36:24.67ID:???0145nobodyさん
2016/10/19(水) 20:38:30.76ID:???それってつまりはPDOがDBの仕様(というかインターフェース)を決めている事に他ならん訳でな。
「他のDBには無いけどPDOがエミュレートしてくれる」なら周りを気にせずどんどん抽象化できるやん？
0146nobodyさん
2016/10/19(水) 20:42:51.81ID:???0147nobodyさん
2016/10/19(水) 20:43:30.59ID:???"DBに委任出来ることは委任する"のが前提
まぁ, 納得してもらわなくていいけど, 「俺の欲しい機能が公式で実装されてない」という主張, そしてそれを実装しろという要望は, ここよりPHPの公式でぶちまけるべきだ
そしてうまいこと公式の開発者たちを説得してくれ, PDOより上のレイヤは実装されている分には構わんからな
0148nobodyさん
2016/10/19(水) 20:47:59.42ID:???sqliteで思い出したけど、PDOってエミュレートどころか使えない機能を使っても使えたフリだけするパターン(トランザクションとか)がかなりあるで。
ミニマムスペックで汎用なように作ってるつもりでも実態は全然目標とは乖離してるがな！
やっぱPDOは勝手に拡張されていくべきだわ。PDOこそがDB操作の標準になるくらいがええ。
0149nobodyさん
2016/10/19(水) 20:53:09.97ID:???0150nobodyさん
2016/10/19(水) 20:57:21.52ID:???なにも汎用性重視のPDOにそんな要求しなくても
0151nobodyさん
2016/10/19(水) 21:00:08.08ID:???ベンダもそれぞれバージョンアップとかで新機能導入していくんやから、様子見てPDOがメインストリームになりそうなのを抽象化して実装するのが筋やろなあ。
0152nobodyさん
2016/10/19(水) 21:03:14.15ID:???ORMではなく。
phpがそれやってくれると普及すると思うんやけどなあ。
0153nobodyさん
2016/10/19(水) 21:06:08.35ID:???そうだねぇ。だからこそ、IN (?) に array をバインドなんてあさってのことやるよりも前にしないといけないことが多いよね。
メインストリームになりそうとかそんな段階の話は遠いよ。そもそも標準への準拠がまちまちなんだから。
0154nobodyさん
2016/10/19(水) 21:08:03.10ID:???in句にarrayを入れられない(いや、入るのかもしれないけど)のは寧ろアンダー仕様なんやないのか？
0156nobodyさん
2016/10/19(水) 21:11:43.49ID:???混同してねえよ。array型を扱えるRDBMSなら、in句にarrayを入れた場合の仕様くらいはちゃんと決めてるはず。
arrayとarrayを比較するのか、それともarrayの中身を展開して比較するのかとか。
そこをPDOでエミュレートするのは難しいはなしでは無いだろ。仕様があるんやから。
0157nobodyさん
2016/10/19(水) 21:11:58.81ID:???0159nobodyさん
2016/10/19(水) 21:13:17.90ID:???0160nobodyさん
2016/10/19(水) 21:13:35.82ID:???0161nobodyさん
2016/10/19(水) 21:15:20.87ID:???> in(1,2,3,4,5)みたいになっているのは、php上で[1,2,3,4,5]になってるのとは等価だろ。
「微妙に分からんが」の言葉の重さよ
0162nobodyさん
2016/10/19(水) 21:16:11.81ID:???どういう結果になるかは分からんけど、in(
:array)が動かないのは寧ろ不自然やろ。PDOであたい入れてもクエリ壊さへんやん。
0164nobodyさん
2016/10/19(水) 21:19:10.14ID:???IN (:array)
に対して $phpArray = (a, b, c) をバインドして得られる結果は IN (ARRAY[][a, b, c]) であって, INの左側式の値がARRAY[][a, b, c]に一致するという意味になるが？
0165nobodyさん
2016/10/19(水) 21:20:34.72ID:???OS
エディタ
ターミナル
0166nobodyさん
2016/10/19(水) 21:21:10.42ID:???分からんけど、そういう動きするならそこから進んでin(
value_explode(:array))
みたいな書き方で大方の目的が達成できたりするんちゃう？
0167nobodyさん
2016/10/19(水) 21:21:52.19ID:???0168nobodyさん
2016/10/19(水) 21:22:10.46ID:???0170nobodyさん
2016/10/19(水) 21:25:45.33ID:???何より即インストールできるし。
0172nobodyさん
2016/10/19(水) 21:31:28.82ID:???0173nobodyさん
2016/10/19(水) 21:35:50.98ID:???よく分からんけどバインドしたタイミングと実際の読み出すタイミングで値変わることがよくあるからアカンみたいな話？
なら値が変わること覚悟でストリーム渡させるとか色々あるやろ。
なんやあんまり明確とは言いづらい気がするのう。
0174nobodyさん
2016/10/19(水) 21:40:01.64ID:???そんなん自動判別しよるのがPDOさん仕様やん。一意じゃないと困るならbindarray(名前、配列、型)メソッド用意したればいいだろ。甘えんなや！
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するより速くなるかもな。
■ このスレッドは過去ログ倉庫に格納されています