================================= 54:データはなるべく物理削除をする ================================= 「 :index:`論理削除` をしたい」という要望はとても多くあると思います。 ですが実際には将来的な開発コストや運用コストが大きくなりますので、安易に導入しないほうが良いでしょう。 なぜでしょうか? 具体的な失敗 ================== .. code:: python class ArticleQuerySet(models.QuerySet): def exclude_deleted(self): return self.filter(deleted_at__isnull=True) class Article(models.Model): ... deleted_at = models.DateTimeField(null=True, blank=True) objects = ArticleQuerySet.as_manager() このテーブル設計では、 ``deleted_at`` というカラムが設定されていれば「削除された」と扱うようにしています。 論理削除はプログラム上扱う状態が増えるのでオススメしません。 すべてのデータ取得に「削除済みでない」という条件が必要になります。 :index:`JOIN` をする際にも条件が常に必要です。 開発の際に常に条件を意識する必要がありますし、誤って実装してしまうと大きな問題になります。 .. omission:: ベストプラクティス ======================= 論理削除をしないのが一番です。 ほとんどの要望、要件に対して論理削除が必要になることは非常に少ないでしょう。 「論理削除がほしい」という要望の背景としては「データを戻せるようにしたい」や「過去のデータを参照したい」が多いかと思います。 その場合、以下のような別の方法で解決できます。 .. omission::