Quelle approche DB Junction est la plus efficace dans ce scénario?

Question

Afin d'éviter une suppression en douceur, je crée une base de données de corbeille. La base de données principale va se connecter à elle. Voici un exemple de deux approches de jonction possibles, et j'espérais obtenir des commentaires sur ce qui serait plus efficace? Pour simplifier, disons qu'il y a deux tables, Order et Invoice (et chaque facture ne comporte qu'une seule commande).

Order 
----- 
OrderId 
InvoiceId 
Description 
Date 
NumberOfStuffOrdered 

Invoice 
------- 
InvoiceId 
Description 
Price 
Tax 
Shipping 

Pour une jonction de ces tables à la corbeille, je ne savais pas quelle approche prendre.

Approche 1:

DeletedOrder 
------------ 
DeletedOrderId 
OrderId 
RecycleBinId 
Date 
Reason 

DeletedInvoice 
-------------- 
DeletedInvoiceId 
InvoiceId 
RecycleBinId 
Date 
Reason 

Approche 2:

DeletedRecords 
-------------- 
DeletedRecordsId 
RecordPrimaryKeyId 
RecycleBinId 
RecordType 
Date 
Reason 

Bien que l'approche 1 prendra plus d'espace de table dans la base de données, il aura moins de lignes par table et ont des temps rapides de requête comme le système mûrit. L'approche 2 consolide la nécessité de créer une table supprimée supplémentaire pour chaque table de la base de données, mais au fur et à mesure que la maturité du système augmentera en taille et deviendra lente à interroger.

Lequel sera le plus efficace dans l'ensemble, ou y a-t-il une meilleure façon d'aborder cela?

Answer 1

Cela dépend de combien vous devez conserver, et comment vous allez l'utiliser. Si vous devez enregistrer tous les détails de vos factures et commandes (NumberOfStuffOrdered, Tax, etc.), les tables de suppression spécifiques sont nécessaires. Si vous avez simplement besoin d'enregistrer le fait que la ligne a déjà existé (ce que vous avez maintenant: Id, type, Date [Supprimé], Motif), nous revenons à «ça dépend».

Si personne n'utilise vraiment les données, si vous avez juste besoin du fait qu'il existait un jour ou l'autre un audit IRS, alors une seule table devrait suffire. (L'analogie est l'entrepôt rempli de boîtes de formulaires remontant à 70 ans - cela prendra du temps, mais vous le trouverez finalement.) Cependant, si vous allez régulièrement accéder à ces données et exécuter des rapports, faites l'extraction de données , ou quoi que ce soit, alors vous feriez mieux de concevoir des tables pour prendre en charge les schémas en étoile normalisés, ou ce qui est utile.

Généralement, je soupçonne qu'une grande table avec quelques index supportant des requêtes fréquentes devrait suffire, à moins qu'une bonne performance soit critique.