J'ai un projet d'application Web qui fonctionne avec une base de données assez grande (plus de 5 Go). Les données de la base de données sont partitionnées par projet. Chaque projet prend environ 1 Go, et c'est un ensemble minimal pour que l'application fonctionne (nous faisons quelques calculs mathématiques qui se propagent à travers cet ensemble de données et la suppression d'une partie de l'ensemble de données n'est pas une option).Comment abordez-vous la gestion des versions de base de données lorsque vous effectuez des builds réguliers?
Dans le cadre de la construction quotidienne, nous déployons également notre application dans un environnement de test. Pour ce faire, un générateur exécute un utilitaire de mise à jour de base de données personnalisé qui met à jour la base de données actuelle vers la version appropriée. Mais nous avons également besoin de conserver tous les builds quotidiens pour que l'équipe QA puisse "remonter dans le temps" et comparer les résultats de calcul de différentes builds. Même si nous essayons d'avoir un schéma de données rétrocompatible parfois, il est très difficile et prend du temps. Donc, d'où la question:
Quelle approche de la gestion des versions de base de données utiliseriez-vous si vous aviez besoin de maintenir les anciennes générations quotidiennes et de gérer une base de données volumineuse tout en faisant des constructions quotidiennes?
Nous utilisons SQL Server 2005 et ColdFusion avec un peu de Java au début si cela fait une différence.