論理削除と一意性制約を両立させる方法・DB製品別 - Qiita

アプリケーション上でなにかエントリ（例えば記事だとかユーザだとか）を削除したとき、DB上の行は削除せず単に【削除済み】フラグを立てるだけという扱い方を 論理削除 と呼びます。 論理削除にはいろいろなメリットがあります。行削除のように関連する他テーブルへ削除が波及しないこと、エントリ復活ができること、障害時にデータ変更の経緯を追いやすくなることなどなど（デメリットもわんさかあるんですが、この記事の主旨からははずれるので別途お調べください）。 ところが論理削除の方針でDBを組んでいて困ったことはありませんか？ 「 メールアドレスは一意性(UNIQUE)制約をかけたいのに、それだと削除済みのユーザと同じメールアドレスが使えないことになる 」 論理削除と一意性制約、両立はできないのか？ できないと思っている方、多いと思います。実はちゃんとできます。DB製品によって実現方法がちょっと違ってくるだけで

[tmatsuu]

statusが0/1以外も取りうるとUNIQUE属性が崩れてしまうので、論理削除専用のカラムがいいかもね。でも実装依存はできるだけ避けたい。バージョニングとか考えだすとこのあたり死ぬ。

[k-holy]

論理削除と一意性制約の実装

[Aoba]

論理削除とUNIQUE制約を両立させる

[kiyo_hiko]

"statusの組をキーに一意性制約をかけます" なるほど

[suginoy]

deleted_atをNULLにするgemがある。 “MySQL, Oracleには部分インデックス機能がありません。しかし、一意性制約がNULLを対象外にする性質を利用すればやはり両立が可能です”

[Sampo]

id:tmatsuu おっしゃる通りで、boolean型のis_aliveカラムとかの方がよさげですね。もっとも、booleanを持っているかどうかがまた製品依存でサンプルコード書きづらくなってくるのですが。

[d_animal141]

SQL - 論理削除と一意性制約を両立させる方法・DB製品別 - Qiita