いろいろ技術的メモ

仕事に差し障りない範囲で、関連ネタなど…

DBアクセス関連

このあたりまで踏み込んでみると、

PHP+Laravel5.x

という環境の凶悪な楽さ加減がわかるわ…w

 

1:準備

zxnw.hateblo.jp

 DBアクセスに成功していること。

コード的には、(以下、PHP5.6.x + 5.0.x環境

  • $ php artisan make:model tasks
    Model created successfully.
    Created Migration: 2017_07_14_080808_create_tasks_table
  • \database\migrations 以下のmigrate用phpファイルでテーブル構造を修正。
    $table->string('name');
    を追加程度で。
  • php artisan migrate
  • Seeder書いて使うなら、このへん。適当に自前insertしても。
  • コントローラ冒頭でuse宣言
    use App\tasks;
  • getIndex()などで
    $tasks = tasks::all(['id', 'name' ]);

 これで全件取得。

 

 

2:ごりごり使う

PHPにはヒアドキュメントあったよね。

もうあれでごりっとSQL書いちゃって、要素部分だけ?にすればいいんじゃね?

$q = <<< EOM
select * from tasks where id= ? order by id;
EOM;
$tasks = DB::select( $q, [ $id ] );

 はい。パラメータクエリ出来た。うわあ。糞楽だのう、これ。w

複数要素のパラメータ放り込みたい時も、第二引数は配列なんで、ここに並べるだけ。お手軽だわー。

 

★ベタ過ぎる件?

クエリビルダとかあるらしいけど、複雑になってビルダに突っ込んだ要素がむやみに増えると、それが本当に意図通りのsqlなのか、あんまり信用出来ねーんだよなー。まぁこんな簡単な単純selectなsqlなら問題や曖昧さなんて起きないだろうけどさー。

あとSQL自体の、個別単体テスト。ヒアドキュメントで書くと、これだけでコピペでテキストエディタ上で要素埋めてDB直に放り込んで、結果確認出来る。でもビルダーに細切れで入れてると、これ、問題起きたときに、どの書き方が悪いのか突き止めるの面倒くさくね?

DB側仕様が未確定の状態で走り出して、もう書いちゃった細切れを、後から仕様変更に合わせて修正も、面倒くさくね?これ、あり得ないって思うかもしれんけど、実作業だと往々にして「仕様確定の方が実装開始より無駄に遅い」なんてザラなんだぜ?w

SQLベタなら、これも対応しやすいし、テストも想定可能だしなー。どうなんだろうね?そのへん。PHPUnitとか使うつもりで書けば、まだマシになる?ならないよなぁ。その前の話だもんなぁ。

 

 

3:その他

DB::insert
DB::update
DB::delete

 このへん。ノリはselectと同じ。

この辺は普通にプログラマやってれば見えるだろうけど、ものすごく定型的な全力で自動化出来るような、決まり切ったSQLを書くことになる。こういうのはビルダ的ツール使うのもありな部分だと思う。

SQLは結局、どうしてもselectは人間が頑張って書く方が、目的に沿ったコード書ける気がするなー。単なるパフォーマンス部分は、DB側のoptimizerが頑張るにしても、ソフトウェア的・仕様的に求められる論理的整合性は判断してくれないからなぁ。