J'ai l'habitude de voir des rangées de tableaux avec des colonnes du type 'DeletedDate' et je ne les aime pas. La notion même de «supprimé» est que l'entrée n'aurait pas dû être faite en premier lieu. Pratiquement, ils ne peuvent pas être supprimés de la base de données mais je ne les veux pas avec mes données chaudes. Les lignes logiquement supprimées sont, par définition, des données froides sauf si quelqu'un veut spécifiquement voir les données supprimées.
De plus, chaque requête écrite doit les exclure spécifiquement et les index doivent également les prendre en compte.
Ce que j'aimerais voir, c'est un changement au niveau de l'architecture de la base de données et de l'application: créer un schéma appelé "supprimé". Chaque table définie par l'utilisateur a un équivalent identique dans le schéma "supprimé" avec un champ supplémentaire contenant des métadonnées - l'utilisateur qui l'a supprimée et quand. Les clés étrangères doivent être créées.
Ensuite, les suppressions deviennent des insert-deletes. Tout d'abord, la ligne à supprimer est insérée dans son équivalent de schéma «supprimé». La ligne en question dans la table principale peut alors être supprimée. Il faut cependant ajouter une logique supplémentaire quelque part sur la ligne. Les violations de clé étrangère peuvent être traitées.
Les clés étrangères doivent être manipulées correctement. Il est déconseillé de supprimer logiquement une ligne mais dont les colonnes primaire / unique ont des colonnes dans d’autres tables qui y font référence. Cela ne devrait pas arriver de toute façon. Un travail standard peut supprimer des lignes veuve (lignes dont les clés primaires ne sont référencées dans aucune autre table malgré la présence d'une clé étrangère. Il s'agit toutefois d'une logique métier.
L'avantage général est la réduction des métadonnées dans le tableau et l'amélioration des performances qu'il apporte. La colonne 'deleteDate' indique que cette ligne ne devrait pas être réellement présente mais, pour des raisons pratiques, nous la laissons là et laissons la requête SQL la gérer. Si une copie de la ligne supprimée est conservée dans un schéma "supprimé", la table principale contenant les données hot contient un pourcentage plus élevé de données hot (en supposant qu'elles soient archivées à temps) et moins de colonnes de métadonnées inutiles. Les index et les requêtes n'ont plus besoin de prendre en compte ce champ. Plus la taille des lignes est courte, plus le nombre de lignes pouvant être insérées sur une page est élevé, plus SQL Server peut fonctionner rapidement.
Le principal inconvénient est la taille de l'opération. Il y a maintenant deux opérations au lieu d'une, ainsi que la logique supplémentaire et le traitement des erreurs. Cela peut entraîner plus de verrous que la mise à jour d'une seule colonne prendrait autrement. La transaction maintient les verrous sur la table plus longtemps et deux tables sont impliquées. La suppression des données de production, du moins selon mon expérience, est chose rare. Même dans l'une des tables principales, 7,5% des presque 100 millions d'entrées ont une entrée dans la colonne 'DeletedDate'.
En réponse à la question, l'application devrait être consciente de la «suppression complète». Il suffirait simplement de faire la même chose dans l'ordre inverse: insérez la ligne du schéma "supprimé" dans la table principale, puis supprimez la ligne du "schéma supprimé". Encore une fois, une logique et une gestion des erreurs supplémentaires sont nécessaires pour éviter les erreurs, les problèmes de clés étrangères, etc.