is_dirty VS last_modified_date dans un db?

Je conçois ma base de données pour que je puisse faire des sauvegardes incrémentielles. Je pense qu'il devrait y avoir un travail hebdomadaire cron qui vide les données dans un fichier tar.bz2 en lecture seule et peut vider la plupart de mes données facilement car il avait une date de modification ou est inséré seulement. Cependant, il y a des choses comme user_profile qui contient le mot de passe et la signature. Comment devrais-je savoir quand cela doit être jeté/mis à jour? devrais-je utiliser un peu appelé is_dirty ou devrais-je avoir une date de modification? Quels sont les avantages et les inconvénients de chacun?is_dirty VS last_modified_date dans un db?

actuellement je suis en utilisant SQLite, je suis le passage à tsql et s'il y a des problèmes i peut passer à MySQL en fonction de mon fournisseur d'hébergement

Source

2010-01-03 Anonymous

L'application de sauvegardes db incrémentielles est fastidieuse, et une douleur royale si vous manquez une étape. Je ne voudrais pas m'inquiéter de l'approche sur SQL Server ou MySQL - c'est ce que sont les journaux de transactions, vous n'avez donc pas besoin de l'incorporer dans votre modèle de données. –

Bien - la création de votre propre processus de sauvegarde incrémentielle n'est pas seulement fastidieuse - elle est très sujette aux erreurs à long terme. Il est courant de trouver des sauvegardes au niveau de l'application qui, au fil du temps, ne sont pas mises à jour pour refléter les nouvelles tables de la base de données. Ou - utilisez un horodatage qui n'est pas mis à jour lorsque vous effectuez une conversion sur la base de données, etc. Juste matière à réflexion ... – KenFar

last_modified fonctionnerait bien, je suggère votre exportation logique de garder ses propres données sur ce a été sauvegardé pour la dernière fois et vous ne prenez pas le chemin d'un drapeau is_dirty. Laissez votre conception de vos données porter sur vos données et laissez votre exportation logique être celle pour suivre ce qui a été sauvegardé pour la dernière fois. Et, avant tout cela, avez-vous regardé à fond pour un système de sauvegarde qui a déjà été écrit? (pourquoi réinventer la roue?)

En outre, une autre considération, une colonne d'indicateur ne s'indexe généralement pas si bien que l'interrogation sur la colonne peut être un réel frein. Sauf si vous utilisez un index bitmap, qui a ses propres mises en garde et les choses à se méfier.

Je conçois toujours toutes mes tables pour avoir un champ entry_date (avec des triggers à supporter) et un mod_date field (encore avec des triggers).

Source

2010-01-03 05:19:12 harschware

Qu'entendez-vous par déclencheurs? les déclencheurs logiques dans le code ou les déclencheurs dans db? (J'ai entendu parler de déclencheurs sqlite mais je ne sais pas ce qu'ils sont). Je n'écris pas un outil pour faire des sauvegardes. C'est juste que je ne suis pas obligé de vider la table entière chaque fois que je veux sauvegarder des données. –

Oui, les déclencheurs sont une procédure stockée qui s'exécute dans votre base de données de votre choix. La plupart, mais pas toutes, les bases de données les soutiennent - sous une forme ou une autre. Dans ce cas, vous devez écrire un déclencheur pour remplir automatiquement vos entry_date et mod_date avec l'heure actuelle lors de l'insertion ou de la mise à jour (respectivement). Vous ne devriez pas vous fier à votre code d'application pour ce faire, pour diverses raisons, mais le plus important serait la synchronisation de l'heure entre les clients. – harschware

Je suggère d'utiliser last_modified car cet horodatage ne serait pas seulement efficace pour votre processus de sauvegarde, mais un tel champ est généralement utile pour le suivi des données. Le fait de savoir si un champ a été mis à jour vous aidera à corriger les problèmes de production (savoir quand un profil utilisateur a été mis à jour et lié à la plainte) et à valider les améliorations apportées à vos mises à jour db.

Source

2010-01-03 05:39:49 akf

is_dirty VS last_modified_date dans un db?

Répondre

Questions connexes