Contents
Observeパターン
主にログや履歴系のテーブルで多いかと思うのですが、あるモデルが更新されると別のモデルもセットで更新される、のようなケースがあるかと思います。
たとえばstockテーブルとstocks_historyテーブルのような関係ですね。
この場合、通常はstockテーブルのあとにstocks_historyテーブルを更新するなどのパターンが一般的です。
このようなときに使われるデザインパターンとしてオブザーバーパターンというものがあるそうです。
辞書的な説明だと、観察される側(=Subject)と観察する側(=Observer)に分かれ、される側のイベントがする側に検知され・・・というような説明になるかと思います。
(上記の例だとstock=Subjectとstock_histories=Observeがそれになるかと思います。)
ただこのページにはもっと非常にわかりやすく書かれており、
「あいつに動きがあったらすぐに伝えろ。こちらもすぐ動く」
と書かれておりました。わかりやすい・・・。
他参考リンクなど
https://qiita.com/shoheiyokoyama/items/d4b844ed29f84a80795b
Laravelで開発をしておりますので、Laravelのobserveパターンも見てみましたが、標準でこう言った機能が搭載されているのはありがたいですね。
他の対策
こう言ったデザインパターンは既存の実装でこのようなケースがよく使われており、その問題点を解決すべく生まれる・・というのが一般的ではないでしょうか。
まあフレームワークなんかもフレームワークがない場合にどのように対応していたか、を考えるとより理解度が深まると思います。
自分はObserveパターンをしらなかったため、この方法以外の場合、以下の２点のような手法が挙げられると思います。
プログラムで頑張って制御
一番一般的な対策手法ですね。stockのinsertのすぐ後にstock_historyのinsertを入れるとかですね。
メリット
- 特別な知識がいらず、誰でもわかること
- 柔軟性があること
デメリット
- 漏れやダブりを常に検討しなくてはいけないこと
- 保守期間などが長くなったり、プロジェクトメンバーの人数が大きくなればなるほど管理コストが上がる
Databaseのtirggerを使う(DB更新系のみ)
ObserveパターンはDBだけとは限りませんが、大概においてDB更新系の処理で関わってくる可能性が高いため、挙げさせていただきました。
自分もtriggerに関してあまり使ったことはないですが、片方のテーブル更新の検知を受けてもう片方が自動的にテーブル更新を受けるという仕組みです。
メリット
- テーブル間の同士のつながりになり、漏れがなくなる
デメリット
- テーブル自体の検知になるため、柔軟性に乏しく、イレギュラー条件分岐などをいれられない
- プログラムと別管理になるので、管理コストが上がる
