スイーツ（笑）と呼ばないで!!

laravelは本当に便利ですね。

いろんな機能がすでに用意されていて、簡単につけたり外したりできます。

システム開発でよくある論理削除。

これもEloquentのModelの頭で

use SoftDeletes;

とか書くだけで利用できるようになります。

これだけで毎回、削除されているものを除く、とか条件をつける必要がなくなります。

削除されたものも含みたい場合は、

Article::withTrashed()->get();

みたいな感じでwithTrashedというscopeを指定するだけで可能。

本当に便利ですね。

ただ、この仕組みには大きな前提があります。

削除の判定はそのテーブルのdeleted_atがnullかどうかで判定する

というものです。

もちろんカラム名は

const DELETED_AT = ‘delete_datetime’;

なんて感じで上書き指定できる柔軟さがlaravelにはあります。

ただ、DB設計者が

「いや、ここはdeletedという1か0のフラグで判定する」

といった場合、ちょっと困りますね。

対処方法は大きく3つあります。

1.用意されているSoftDeletesの仕組みは使わない

毎回、where(‘deleted’,’=‘,0)とかって指定するパターンですね。
どうやら、皆この方法をとっているようです。

2.自前で論理削除の仕組みを実装する。

　　自分でdeletedを使ったtraitとdeletedを使ったグローバルscopeを用意します。
　　それなりに面倒ではありますね。ただ、deleted_byとか追加したりいろいろカスタマイズができます。

3.deletedではなく、deleted_atのnull判定を使うように説得する。

　　DB設計者はそこまでこだわりはないかもしれません。
　　毎回、where(‘deleted’,’=‘,0)と書く手間や、書き忘れによるバグが出るよりは良い、と判断するかもれません。


この週末に2のパターンで実装してみました。
一応、ちゃんと動きましたね。

ただ、deleted_atを使わず、deletedを使うためだけにこの仕組みをやるのは少し大げさかなと思いました。

私はDB設計をする側の立場ですが、いろいろバランスを考えると、laravelの標準のまま使う3の案が良いのではないかと思いました。

これはちょっと他のSEやPGたちと話し合いたいところです。
必ずしも統一する必要があるところではないと思いますが。

合わせて、created_by、updated_by、deleted_byといったデータの作成・更新・削除を行ったuser等のメタ情報の管理についても話し合いたいと思っています。

laravelにはmodel eventsという仕組みがあり、例えば、データが作成されたタイミングなどをイベントリスナーで取得し処理を実行させることができたりします。

例えばそのタイミングでログを作成することなどで、代用が可能かもしれません。
createdではなく、creatingでメタ情報をセットするのもあるかもしれません。
ただ、model毎にイベントリスナーを登録するのは面倒ですね。

今のところメタ情報更新用のtraitを作成し、modelでuseするのが一番手間では無い気がしています。

ということで、最終結論はでていませんが、同じ目的が達成できなるなら、楽でミスが少ない方法が良いですね。

[1回]

• プログラミング
• COMMENT：0