以前投稿したbulk insertで大量のデータをDBに登録するの記事では10万レコードの挿入をbulk insertで行い、通常のinsertと比べてどれだけ速くなるのか検証しました。結果は一目瞭然で、大量のレコードをDBに登録する際には強力な武器になる事が分かりました。 しかし、前回のコードを実際の運用で使うには１つ問題があります。それはbulk insertの途中でエラーが発生した場合、DBに中途半端にレコードが残ってしまうという問題です。今回はこの問題を解決するために、前回のコードをtransactionに入れ、エラーが発生した際にロールバックされるように改修します。そして、transaction処理にする事でパフォーマンスにどのような影響があるか検証してみます。
毎日走らせているcronのジョブの１つが、なかなか時間が掛かるのでどうにか改善できないかと悩んでいました。DBへデータを挿入する箇所で時間が掛かっており、コードを確認するとforループで１レコードずつinsert処理を行っていました。bulk insertするように改修したところ、劇的に処理時間が短くなりました。今回はそんな妙薬、bulk insertについてです。
DB変更の履歴の作成をトレイトで簡単にEloquentのモデルに装着できるとしたころまでが前回ですが、巷では似たような仕組みでより良いパッケージがすでにあります。今回はそれを紹介します。
前回のDB変更履歴保存のメカニズムは、Userのモデルのためだけですが、どのモデルでも同様なことが簡単にできるようにトレイトを作成してみます。
前回においては、Eloquentのbootメソッドを利用してDB変更の情報（監査の情報）を取得することができました。今回は、これをDBに記録する部分を考えてみましょう。
データベースに保存されているデータはいつも現時点での値であり、過去の値は保存されていません。しかし、レコードのデータがどう変更したかという情報は重要です。どう変更したかだけではなく、誰がいつ、アプリのどの機能を使用して、さらにはどういう理由で、という情報も必要になってきます。例えば、カスタマサポートにおいて、会員の住所が変更されて注文した商品が届かなかったとき、それらの情報があれば、いついつにお客様が住所を変更しましたね、とか即答できます。さて、これらの変更イベント時の変更情報（監査あるいはAudit情報）、Laravelではどのように効率的にDBに保存することが可能でしょうか？
前回において、Laravelの読み込みと書き込みのDBを自動使い分け機能により、プログラムの設定だけで簡単にDB負荷を緩和できることを知りました。今回は、DBのトランザクションにおいてその機能の振る舞いをチェックしてみます。
前回の「個数管理」のコードに少し肉付けをして実際に近いケースを考慮してみます。
商品の在庫数管理など一般的な個数管理に必要とされる、Eloquentのメソッドdecrementを紹介します。
LaravelのEloquentのModelを継承したクラスで定義できるアクセッサーはとても便利です。しかし、どうして、あたかもDBテーブルにある項目のようにアクセスできるのか不思議に思ったことありませんか？
