Je dis que c'est une mauvaise idée, en général (à quelques exceptions près, peut-être).
Tout d'abord, votre base de données doivent être sauvegardées régulièrement, de sorte que vous ne devrait jamais être dans une situation où vous ne voudriez pas perdre les données de manière permanente en raison d'une SUPPRESSION (sauf si c'est une suppression de la juste ajouté des données, bien sûr).
Deuxièmement, un doux supprimer comme ceci signifie que vous pouvez désormais inclure un WHERE IsDeleted = false clause dans chaque requête sur ce tableau (et tant pis si vous êtes l'Adhésion à ces tables). Une erreur ici serait pris dès qu'un utilisateur ou un testeur remarqué un enregistrement supprimé montrant encore, ce qui peut prendre un certain temps. Aussi, il serait facile pour un développeur d'omettre la clause where de COUNT(*) les requêtes, ce qui pourrait prendre encore plus de temps pour découvrir (j'ai travaillé sur un projet où cela avait été le cas pendant des années, pas beaucoup de dossiers ont jamais été "supprimé", de sorte que les totaux de près à ce qui était prévu et personne n'a remarqué).
Enfin, un doux supprimer va travailler sur une table avec des clés artificielles, mais aussi, potentiellement, ne fonctionne pas sur une table avec une clé primaire (par exemple, vous "effacer" quelqu'un à partir d'une table assortie, par Numéro de Sécurité Sociale - que faites-vous quand vous avez besoin d'ajouter lui revenir? Merci de ne pas dire "inclure IsDeleted dans un composé clé primaire".).
Dans une revue de la conception, je m'attends à ce que le développeur à démontrer une prise de conscience des coûts et des avantages et de présenter une excellente raison pour faire du soft supprime de cette manière. "Pourquoi ne pas le faire?" n'est pas une excellente raison.
