On dit ici:
http://www.ibm.com/developerworks/web /Library/wa-dbdsgn2.html
Chaque table de la DB devrait avoir une table d'histoire, reflétant l'ensemble de la Histoire de la table principale. Si Les entrées dans la table principale doivent être mis à jour, l'ancien contenu de la Les records sont d'abord copiés à l'histoire table avant que la mise à jour soit faite. Dans de la même manière, supprimé des enregistrements dans le La table principale est copiée dans la Tableau d'histoire avant d'être supprimé du primaire. L'histoire Les tables ont toujours le nom de la premier principal, mais avec _Hist annexé.
in temporal db Voir ici modélisation et normalisation de la base de données temporelle Il n'y a pas de Table séparée aussi loin que je comprends.
Alors, quand devrais-je créer une autre table ou non?
3 Réponses :
Les tableaux d'historique fournissent des antécédents de modifications (généralement non temporelles) apportées aux enregistrements de base de données principaux par les utilisateurs. Cette histoire est de nature archivistique (c'est-à-dire accessible de temps en temps à des fins historiques). Les informations temporelles (lorsque le changement a été effectué) est de nature secondaire.
Une base de données temporelle est conçue spécifiquement pour exécuter des requêtes de temps contre. Les informations temporelles sont de nature primaire et maintenues en ligne pour une récupération immédiate. Une deuxième table n'est pas créée, à moins que l'archivage ait également besoin de se produire.
Cela signifie que le choix des critères dépend du traitement des données?
Cela dépend de la nature et de l'utilisation de la récupération de données. Les tables historiques ne sont généralement accessibles que lorsque quelqu'un doit savoir qui a fait une modification, quel était le changement et quand le changement a été fait. Les bases de données temporelles sont conçues spécifiquement pour effectuer des requêtes sur le temps sur les données qui n'ont rien à voir avec l'historique de révision. Donc, les deux sont assez différents.
+1. J'ai ajouté des considérations pratiques concernant la performance dans ma réponse.
De plus, des tables d'audit parfois sont utilisées pour envoyer une liste complète des modifications apportées à la base de données clonée (par exemple, entrepôt de données).
Qu'est-ce que Robert a dit théoriquement - rien à ajouter.
pratiquement , table temporelle vs. Main + Hist Tableau, a d'autres impures.
Pour des données fortement maintenues (par exemple, les mises à jour / suppresses dépassaient considérablement les inserts), ayant un historique (parfois également appelé "Audit" - comme il s'agit du mécanisme principal d'appliquer la piste d'audit de la DB Data) permet de garder le principal Tableau raisonnablement petite taille comparée à la conservation des informations d'audit dans la table principale elle-même. Cela peut avoir des implications de performance significatives pour les sélectionneurs et les insertions sur la table principale, notamment en ce qui concerne l'optimisation de l'index décrite ci-dessous.
en haut de la page, les indices sur la table HIST / Audit n'ont pas besoin d'être 100% identiques à la table principale, ce qui signifie que vous pouvez omettre des indices non nécessaires pour interroger les données d'audit de la base de données HIS (aboutissant ainsi à des inserts dans la table d'audit) et, inversement, optimisez les index de requêtes d'audit spécifiques que vous avez (y compris la commande de la table par horodatage via un index en cluster) sans seller la table principale avec ces indices qui ralentissent les modifications de données (et en cas de regroupement à la mise à jour de la mise à jour. , Clash avec l'indice en cluster de la table principale afin que vous ne puissiez généralement pas l'avoir regroupé dans l'ordre temporel).
La table d'histoire qui est parlée dans cet article de développement est une table qui détient l'historique de la base de données (c'est-à-dire l'historique de nos croyances sur la réalité).
Le genre d'histoire que vous avez posée sur cet autre fil détient notre conviction (actuelle!) Croyance sur l'histoire de la réalité.
Notez la différence. Les deux concurent seulement dans la mesure où nos croyances passées sur la réalité ont effectivement été correctes. Et ce n'est pas toujours à 100%.
Si vous utilisez le premier comme étant comme étant ce dernier, alors vous en pensez que ce degré de concurrence est en effet 100%, c'est-à-dire que toutes vos croyances passées sur la réalité toujours et par définition coïncidaient avec la réalité, c'est-à-dire que vous en pensez qu'il est impossible que vous ayez eu une croyance défectueuse sur la réalité.
Les tables qui détiennent l'historique des autres tables peuvent être conçues en fonction de l'audit. Les tables qui détiennent l'historique de la réalité ne peuvent convenir à l'objectif de tout utilisateur qui s'intéresse à cette information historique.