Q&A
どのような理由で「論理削除」を組み込んでいるのでしょうか。
部署テーブル：
-- 部署ID , 部署名
社員テーブル:
-- 社員ID , 社員名 , 部署ID（外部キー）
上記のような構成があった場合に、
部署を物理削除した場合は mysql により整合性が保たれると思いますが、
部署を論理削除した場合は特に整合性が保たれることなく、社員テーブルの部署IDは論理削除されたIDを持つことになります。
私はこの状態に違和感を覚えます。
mysql 自体には論理削除という概念がないためこうなるのは当然ですが、
mysql を使うアプリケーションやフレームワーク側で整合性を保つべきではないのか？と疑問に思っています。
具体的にいうと、外部キーの削除時の制約に
RESTRICT が指定されているなら、部署を論理削除した場合に参照する社員レコードがあるなら例外を投げる。
CASCADE が指定されているなら、部署を論理削除した場合に参照する社員レコードも削除する。
これらをアプリケーション側などで実装する。という感じです。
このような動作をすると困ることがあるでしょうか？
他の方の意見を聞いてみたく、投稿させてもらいました。
困ること以外でもどんなことでも構いません。よろしくお願いします。
追記20190705
・この部署テーブルと社員テーブルに限った話ではなく、「どのような場合であれ、論理削除でも外部キーによる参照整合性の適用は必要ではないか？」という質問です。
回答2件
0
ベストアンサー
論理削除した状態に外部キー制約と同等のものを制約とするのは別におかしなことではありません。
MySQL8.0以降ならCHECK制約が利用できますが、それ以前だとトリガーでの実装になるかと思います。
以下はトリガーを使用しないで実装されています。
MySQL 5.7で生成カラムを使ってCHECK制約もどきを実装する
ただ、そういった制約に意味があるでしょうか？
論理削除された部署とそこに所属していた社員という関係は特におかしくはないですよね。
現実的には廃止された部署に所属していた社員は別な部署に所属するはずですから、部署IDが新しいものに更新されるのでしょう。
外部キー制約があると、社員テーブルの部署IDを新しいものに変更してからでないと部署を削除できないので、論理削除でその状態を回避しているように見えます。
投稿2019/07/02 14:36
総合スコア25430
貴重なご意見ありがとうございます。
CHECK 制約というのがあるんですね。調べてみたいと思います。
-----------
論理削除された部署とそこに所属していた社員という関係は特におかしくはないですよね。
現実的には廃止された部署に所属していた社員は別な部署に所属するはずですから、部署IDが新しいものに更新されるのでしょう。
-----------
外部キーとなる部署IDは「所属している部署」を表すのであって、「所属していた部署」を表すわけではないですよね。
なので個人的には「社員は〇×部署に所属していた」ではなく「社員は既に存在しない〇×部署に所属している」と捉え、だから「おかしい」と感じています。
実際、そのままではおかしいということもあって社員を存在する部署に移すのだと思います。
その「そのままではおかしい」ということを部署を削除するときに、「まだ社員が所属しているよ！」と気付かせてあげる方が、たとえ一瞬でも「おかしい」状態を作らなくて済むのではないか、と思います。
-----------
外部キー制約があると、社員テーブルの部署IDを新しいものに変更してからでないと部署を削除できないので、論理削除でその状態を回避しているように見えます。
-----------
論理削除は、外部キーの制約の煩わしさを回避するために使われることがあるものなのでしょうか？
だとしたらせっかく整合性を保ってくれるのにもったいないですね。
（一応言っておくとこの「部署テーブル」「社員テーブル」は質問にあたって私が適当に考えたものです。）
> 外部キーとなる部署IDは「所属している部署」を表すのであって、「所属していた部署」を表すわけではないですよね。
それは、部署テーブルの論理削除の状態をどのように捉えるかによります。
物理削除にせず論理削除するのが実際に物理削除されるまでの経過措置なら、「所属していた部署」を表す情報はシステム的に不要という事ですので、仰る通りです。
但し、物理削除はしないというなら、論理削除した部署IDに紐付いている状態の社員データは、論理削除されていないデータに紐付くまでの一過性の状態として解釈されているという事ですね。
論理削除が廃止された部署を表すとして、部署が廃止されたと同時に退職された方は新しい部署IDは振りようがありませんがどうしますか？社員データを物理削除しますか？
詳細に情報を管理する場合、履歴データとして管理する必要があるので、どこまで管理するのかの仕様が明確でない限り、一つのテーブルの論理削除だけに着目して、その関係を議論してもあまり意味が無いですけどね。
提示されているテーブルの構造であれば、細かく人事情報を管理する必要がないシステム想定ですから、最新の情報だけあれば良くて、基本的に物理削除すれば良いだけに思います。
そこに、論理削除を追加するなら、物理削除までの一過性の措置にしか使えないですね。
それであれば、制約など考えずに、チェックリストなどを作成する方が使い勝手は良いかと思います。
> それは、部署テーブルの論理削除の状態をどのように捉えるかによります。
なるほど。論理削除をどう扱うのかは色々ありそうな感じですね。
> 但し、物理削除はしないというなら、論理削除した部署IDに紐付いている状態の社員データは、
> 論理削除されていないデータに紐付くまでの一過性の状態として解釈されているという事ですね。
そういう解釈もあるのですね。
saziさんの経験上「一過性の状態が必要」な場合がありましたか？
もし記憶にあれば教えていただけるとさらに参考になります。
> 論理削除が廃止された部署を表すとして、部署が廃止されたと同時に退職された方は
> 新しい部署IDは振りようがありませんがどうしますか？社員データを物理削除しますか？
「退職した社員のデータは削除する」という仕様なら削除すると思います。
仮に社員データに「退職」というステータスを持たせて削除はしない仕様の場合は、
「論理削除でも外部キー制約を適用する」仕組みと相反する仕様になりますね。
> 一つのテーブルの論理削除だけに着目して、その関係を議論してもあまり意味が無いですけどね。
私の質問の仕方が悪かったかもしれません。このテーブル構造に限っての話ではなく、
「どのようなテーブル構造であれ、論理削除で外部キーの制約を適用したほうがいいのではないかと思うのですが、よくない場合はありますか？」という質問でした。
ですが、状況次第では「論理削除でも外部キーの制約を適用する」のは注意が必要そうですね。
> 経験上「一過性の状態が必要」な場合がありましたか？
物理削除前にそのデータをCSV等で抽出保存してから削除するという場合がありました。
データの関係上の制約は当然あるものですけど、外部キー制約だけでは全てを網羅できない場合があるので、個人的には、DBへ制約を設定する事は殆どなく、更新時のロジックで対処するのが殆どですね。
なるほど。参考になりました。ありがとうございます。
0
Laravelだと、以下ライブラリでSoft DeleteでのCascade、Restrictの参照整合性を保つ機能を実装可能です。
https://github.com/Askedio/laravel-soft-cascade
物理削除は、forceDeleteを使います。
投稿2019/07/04 04:57
編集2019/07/04 04:58
総合スコア4106
情報提供ありがとうございます。
実は自作で laravel の softDeletes を拡張して、論理削除時に DB に設定された外部キーの制約をもとに参照整合性を保つ仕組みは作成済みではあるのですが、同じようなことを考えている人がいてうれしいです。
あなたの回答
tips
プレビュー
