のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,908人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレ【PHP】下らねぇ質問はID出して書き込みやがれ 114

    php覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    253 = :

    だれか翻訳頼む

    256 = :

    一回PHPのクラスで何が出来るか勉強してくるべき

    257 = :

    クラスを知らないか、理解していない人の相談なんです。

    258 = 252 :

    すみません。クラスをちゃんと理解していませんでした
    class SQLの中にrecordというファンクションがなかったので
    もともと用意されている何かだとおもったのですが
    ググってもでてこなかったので聞いてみました。

    まだよくわかっていないのでちょっとクラスについて調べてきます

    259 :

    DBを使ったサービス作るんだけど、
    DB操作しやすいライブラリとかでおすすめないかな?

    プログラム自体は大したことないのに、
    テーブルやらカラムやらを大量に作らなきゃいけない予定なんで、
    SQLで書くのめんどくさいから、
    ソースコードだけで片付くものを探してるとこなんだけど

    260 = :

    もっと頭を柔らかくしようよ
    $this->recordが必ずしもファンクションとは限らないのにファンクションと決めつけてるだろ
    そんなことだといつまでも謎のままだぞ

    >if ($limit) return array_slice($this->record, $offset, $limit);
    これ見たらあー配列なんだなってわかるし
    つーことは、名前からしても$this->recordにはどこかでSELECTの結果かなにかを配列としてセットしてるメンバだとわかるだろう

    261 = :

    >>258
    recordというデータメンバもないですか。
    親クラスがあればそちらにも

    263 = :

    >>259
    そーゆーことならフレームワークのスレへ
    ただSQL書かないで最適なクエリを発行することはまず無理だと思う
    DB抽象化ライブラリがインデックスまで把握して最適なクエリを発行してくれるものがあればオレも欲しい

    266 = :

    >>264
    まぁいい
    とりあえずクラスってなぁに?どう使えてどう動くの?ってことを30日間勉強して

    268 = :

    >>263
    了解
    おもしろそうだから、一回自作できるか挑戦して、それでもダメだったらどこかのFW探してみます

    269 = :

    >>268
    使う機能だけを関数化すればよい。
    SQLはコマンドラインでも動作する。難しければそこからやってみてそのあとPHPにするというのもある。

    270 = :

    >>269
    何言ってるのこのひと
    すごく的外れ

    274 = :

    $this->$recordと記述してしまうと、
    $recordという変数を探して、
    名無しの変数なんてねえよ。とわめいたり、
    素知らぬ顔で空データ返してくれるPHPを見てると
    ちょっと萌えるよね。
    こんな技法滅多に使わないけど。

    275 = :

    自分でフレームワークライクなもの書いたりする場合によく使うよ
    /hoge/fugaというアクセスはclass hogeのfugaメソッドを実行とかね
    どんな名前でアクセスしてくるかわからないものを一箇所で処理しようと思ったら便利でしょ

    279 = :

    プログラムミス

    281 = :

    とりあえずマニュアル嫁
    http://www.php.net/manual/ja/function.mysql-query.php

    mysql_query() は、 ひとつのクエリを送信します (複数クエリの送信はサポートしません)。

    282 = :

    >>279
    適当にいうな
    >>280
    ありがとうございます
    >>281
    クエリのパースってmysql側でやるものだと思ってたのですが
    そういうものなのですか
    ありがとうございました

    283 = :

    >>280の言うようにmysqliのほうが速いしなにかと捗るぞ
    mysqliのmulti_queryはマルチクエリ実行できるよ

    ただ得意気に
    >そして○○_query系でsqlを実行するのは今すぐやめましょう
    >これからは○○_prepareを使いましょう
    とか言ってると笑われるから注意な

    すべてケースによるから自分で最適なコーディングを探すこと
    エスケープやアプリに合わせたサニタイズも考えながらやって

    284 = :

    適当だったが、Sqlite3、PDOの関数では複数行の一括処理できるが。
    Sqlite2の古い関数使うからダメなんだ。

    285 = :

    >>284
    何言ってるのこのひと
    SQLite関係ないでしょ
    PDOの話もしてないし

    286 = :

    ○○_prepareはわずかに速くなるだろうが大差ない。
    ボトルネックでないだったら直に送信した方がソースは短くて済む。
    決定的な差になるのはトランザクション指定。

    287 = :

    ほんとだ。データベースは主にSqliteを使うからそれだけの様な気になってた。

    289 = :

    だからケースによるだろう
    そもそもprepareは速く実行するためのものじゃねーし
    エスケープを機械的にほぼ保証してくれるから使えるところでは極力使うべき

    おまえ>>269,>>284だろ
    ずっと明後日の方向見ながらレスしてるぞ
    知ったかぶりにも程があるぞ

    291 = :

    >>290
    これ
    >バッファに取得しないで結果オブジェクトを返します。 エラー時には FALSE を返します。

    バッファに取得しないってことはなんらかの方法で現状をキープする必要があるでしょ
    テーブルロックしてるかどうかしらんけど、してる可能性は高いよ

    だからバッファリングしてから使うべき(このメソッドはあまり使うべきではない)ってことになるんじゃね

    292 = :

    PHPのお馴染み特定厨さん降臨キタ-ーーーーーーー!

    293 = :

    >>290
    ちなみに
    >二種類のモードのうちMYSQLI_USE_RESULT
    >というのが、従来のmysqによる結果セットと同じなのかなと思うのですが
    こういう変な固定概念的なものは取り払って素直にゼロから学習しなさいな
    じゃないと自分の思うようにいかないことばかりでイライラすることになるよ
    一応mysqliでSELECTを投げる場合の標準的な手順だけ
    1. プリペアドステートメントセット
    2. クエリ実行
    3. 結果オブジェクト取得
    4. オブジェクトから結果(レコード)取得
    概ねこんな感じ

    294 = :

    >>291
    データ取得している間中ロックするとか
    なんかありえない処理に思えるのですが・・・
    同時に一人しか同一テーブルを読めないってことでしょう
    いやありえない
    mysqliがおかしいのか
    今までも実はそうだったのか・・・

    295 = :

    >>294
    >>293読んでね
    で、他にメソッド色々あるでしょ?マニュアル熟読してみてよ
    しかも読めないとは書いてないじゃん、更新できないとは書いてあるけど
    イロイロと勝手にわかったフリするのは学習の妨げになるよ

    296 = :

    >>293
    プリペアドステートメントを使う以外は従来と同じですね
    あまり気にせず、
    データが巨大な場合はmysqli_store_result
    そうでない場合はmysqli_use_result
    を使っておけばいいのかなぁ

    297 = :

    >>291を理解できるまで何回か読んで考えてみたら
    バッファリングせずにデータを読みたい場合とバッファリングしてからデータを扱いたい場合で変わってくるでしょう
    前者はクエリを投げた時の状態を固定したままにしておきたいような場合に使えるでしょう
    後者は別にデータ取得直後に変更が加えられても問題ない場合に使える
    通常どちらを使えば良いかは考えなくてもわかるよね

    >データが巨大な場合はmysqli_store_result
    >そうでない場合はmysqli_use_result
    どうしてこういう考えに至ったのかオレにはわからんけど、マニュアルの読解力もしくは理解できるまで辛抱強く読む努力が必要だと思うよ
    なんとなくわかった気になるのが一番マズイ

    298 = :

    …prepareは本来パフォーマンスをあげるためのものだよ。
    何でもかんでも使えばいいってもんでもないけど。

    299 = :

    >>286>>298は同一じゃん
    おまえわかりやすくていいけどいい加減うぜーよ
    しかもおまえ上で暴れてたニートのおっさんじゃん

    300 = :

    >>299
    証明ができなくてすまんが、おっさんにレスをしてた>>202とか>>232は俺ね。


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について