Il s'agit d'un problème courant dans la conception de bases de données :la question de savoir s'il faut séparer ou « archiver » les enregistrements qui ne sont plus « actifs ».
Les approches les plus courantes sont :
- Tout dans un seul tableau, marquez les commandes comme "complètes" le cas échéant. Avantages :solution la plus simple (à la fois en termes de code et de structure), bonne flexibilité (par exemple, commandes faciles à "ressusciter"). Inconvénients :les tables peuvent devenir assez volumineuses, un problème à la fois pour les requêtes et, par exemple, pour les requêtes. sauvegardes.
- Archiver les anciens éléments dans un tableau séparé. Résout les problèmes dès la première approche, au prix d'une plus grande complexité.
- Utilisez une table avec un partitionnement basé sur la valeur. Cela signifie logiquement (pour l'application) que tout est dans une table, mais en coulisses, le SGBD place les éléments dans des zones distinctes en fonction de la ou des valeurs de certaines colonnes. Vous utiliserez probablement la colonne "complète" ou la "date d'achèvement de la commande" pour le partitionnement.
La dernière approche combine en quelque sorte les bons côtés des deux premières, mais nécessite un support dans le SGBD et est plus complexe à mettre en place.
Remarque :
Les tables qui ne stockent que des données "archivées" sont communément appelées "tables d'archives". Certains SGBD fournissent même des moteurs de stockage spéciaux pour ces tables (par exemple MySQL), qui sont optimisés pour permettre une récupération rapide et une bonne efficacité de stockage, au prix de modifications/insertions lentes.
