Nous envisageons de restructurer nos processus de développement et de déploiement de bases de données à l'aide de DBGhost, nous souhaitons nous éloigner de la base de développement centrale et apporter la base de données au contrôle source.
L'un des problèmes que nous avons est une grande table avec des données statiques (contenant des chaînes de langue traduites), il a près de 200K lignes.
Je sais que notre meilleure solution est de déplacer ces piqûres dans des fichiers de ressources, mais jusqu'à ce que nous l'implémentions, DbGhost pourra-t-il conserver toutes ces données statiques et générer nos bases de données de développement et de déploiement rapidement? Et sinon, y a-t-il une bonne alternative à remplir ce tableau quand il le faut?Grandes tables de données statiques avec DBGhost
Répondre
Pourriez-vous jeter un oeil à SQL Source Control? Nous venons d'ajouter un support de données statiques et nous recherchons des commentaires avant la version complète.
http://www.red-gate.com/MessageBoard/viewtopic.php?t=12298
Seriez-vous en mesure d'expliquer pourquoi vous vous déplacez loin d'un modèle de développement de la base de données centrale?
DBG est pas vraiment conçu pour déplacer des quantités massives de données
C'est d'un courriel reçu de Innovartis au sujet de la même question que le vôtre. Vous avez probablement déjà découvert cela maintenant! Peut-être que lorsque vous avez demandé cela, ils n'ont pas eu d'évaluation, même si je ne suis pas sûr que ce soit vrai.
Quelle version utilisez-vous? En V5, il y a eu de très belles augmentations de performance que j'ai vues de mes propres yeux. http://www.innovartis.co.uk/v5whatsnew.aspx – Kuberchaun
La seule façon que vous saurez est de le tester et de voir comment cela fonctionne.
Ceci est une question plus d'une réponse acceptée, mais j'ai une autre entrée dans ce. Nous utilisons DBGhost et nous avons beaucoup de données de table statiques, bien que la plus grande soit seulement environ 20K rangées, plutôt que 200K rangées. DBGhost dispose d'une fonctionnalité pour les données de script (sous la forme d'une série d'instructions d'insertion). Nous avons utilisé cela pour exporter nos données statiques dans des scripts et mettre ces scripts sous contrôle de version. Nous avons modifié ces scripts pour effacer les données avant de les réintégrer, afin que nous puissions utiliser un seul script pour "réinitialiser" les données statiques d'une table. Cet ajout était pour nos besoins spécifiques, et n'est pas le seul moyen de gérer les données statiques avec DBGhost.
Les processus "construire à partir des scripts" et "synchroniser" prennent tous deux en charge les scripts ad hoc de runnning avant et après le processus. Nous avons ajouté les scripts de données statiques en tant que scripts ad hoc à exécuter après la construction/synchronisation. DBGhost prend également en charge la synchronisation des données dans le processus de synchronisation. Le processus de synchronisation peut être configuré pour effectuer une synchronisation des données sur des tables sélectionnées. En utilisant cette technique, vous pouvez demander à votre processus de construction d'ajouter les données via les scripts, puis le processus de synchronisation peut synchroniser automatiquement les données pour ces tables. En utilisant cette technique, vous n'auriez pas besoin de changer les scripts comme nous l'avons fait.
Salut, merci pour votre réponse, nous avons déjà fait quelques tests avec Sql Source Control, puisque nous utilisons d'autres produits de Redgate cela peut être une bonne option pour nous. Je ne pense pas que nous avons examiné dans le support de données statique, seule la structure. (Pour des raisons techniques et de gestion, nous sommes toujours en attente de changement du modèle de développement de notre base de données centrale) – pauloya
Il y a deux raisons principales de vouloir abandonner le modèle de développement de bases de données centrales.1: Isolement - les développeurs se mettent en colère quand quelqu'un change une table ou des données qui cassent les tests sur lesquels l'autre travaille. 2: Gestion du changement - nous ne pouvons pas savoir qui a changé quoi et nous ne pouvons pas obtenir facilement l'historique des changements. – pauloya
@Paulo - SQL Source Control 2 prend désormais en charge les données statiques. Ce serait génial si vous pouviez essayer à nouveau et laissez-nous savoir si elle répond maintenant à vos besoins. –