dans une application Web, comment maintenir la structure de la base de données à jour?

Question

Si vos données changent après le déploiement de l'application, comment maintenez-vous la base de données à jour?

Je veux dire, vous pouvez ajouter ou supprimer un tableau, c’est une tâche simple. Modifier une table existante peut aussi être trivial. Mais si vous changez souvent la structure, comment la maîtrisez-vous?

J'avais l'habitude de garder une table avec une version actuelle de la base de données dans la base de données. Chaque mise à niveau était alors un fichier SQL qui faisait son travail - créer une nouvelle table, ajouter une colonne ou déplacer les données. Les fichiers ont été nommés d'après ces versions. Ainsi, si mon script de mise à niveau obtenait la version 10 de la base de données, il ne restait que tous les fichiers de 11.sql à N.sql et les appliquait en incrémentant simultanément le numéro de version de la base de données.

Cela semble bien fonctionner, mais je me demande quelle est votre stratégie pour de telles tâches?
De plus, ce système ne semble pas parfait si je normalise une table dans un "patch". et après cela, je le dénormalise à nouveau pour une raison quelconque. Ensuite, c'est fait deux fois.

Cependant, écrire un script de mise à niveau complet chaque fois que je modifie quelque chose semble douloureux et sujet aux erreurs. Au moins plus que de tels changements atomiques.

De plus, je peux m'attendre à ce que différents clients disposent de versions de base de données différentes à tout moment, je dois donc vraiment pouvoir remonter de n'importe quel point.

Answer 1

Personnellement, j’utilise un processus très similaire à ce que vous avez indiqué, je peux voir votre argument au sujet des changements, mais TRES rarement, j’apporte un changement, puis je le rétablis à l’ancienne sur un site de production. Dans les tests, oui, cela se produit, mais en ce qui concerne un site de production réel, je ne vois pas cela comme un gros problème.

En conservant des scripts de version individuels, IMHO est non seulement bon pour le déploiement, mais également pour fournir des éléments pouvant être archivés dans le contrôle de source.

Answer 2

De nombreux frameworks utilisent le concept de "migrations". - les scripts qui mettent à niveau votre schéma de base de données d'une révision à la révision suivante. De même, il est généralement utile d’utiliser le script de rétrogradation, au cas où vous auriez besoin d’annuler une modification. Parfois, ces scripts sont en SQL, parfois ils sont abstraits (par exemple, Ruby on Rails). Vous pouvez concevoir ces scripts à la main ou utiliser un outil tel que SQL Compare, mentionné par d’autres.

Il est également utile de créer une table dans votre base de données avec une colonne, une ligne, pour indiquer la révision du schéma. Certains frameworks prenant en charge les migrations s’appuient sur cela pour savoir quels scripts de migration appliquer pour mettre à niveau ou rétrograder le schéma.

Votre application doit comporter une suite de tests que vous pouvez exécuter pour valider ses fonctionnalités. Vous pouvez également ajouter à cette suite des tests fonctionnels qui inspectent le schéma et confirment que les tables, colonnes, procédures, etc. attendues existent. Lorsque vous révisez le projet, révisez les tests. Les tests de fonctionnalité des applications doivent être suivis dans le contrôle de source avec le code qu'ils testent, les tests de structure de schéma doivent également être suivis.

Enfin, la conception de la base de données constitue la base de la conception de votre application. Une ingénierie logicielle appropriée devrait aboutir à un schéma de base de données relativement stable avant le déploiement. Les modifications ultérieures du schéma de base de données doivent être à la fois petites et rares.

Answer 3

Tout d'abord, nous avons introduit une table de versions, le schéma qui suit le numéro de version de l'application pour laquelle le schéma est défini, et nous suivons la version de chaque table non standard. nous avons une version de schéma que nous codons en dur dans l'application pour la comparer à cette version de l'application. Nous ne voulons pas que l'application accède à la mauvaise version de la base de données. nous avons ensuite un ensemble de scripts pour chaque table qui migre de la version précédente de la table vers la version actuelle. nous avons ensuite une table cible que nous intégrons dans l'application pour savoir quelle version de chaque table est attendue dans la nouvelle version pour voir si nous correspondons à tout. sinon, nous appliquons les divers scripts de migration au schéma pour obtenir la base de données à priser.

compliqué? quelque peu. sauver des vies. absolument. Rien de tel que la poursuite des erreurs dans une application, car le schéma est erroné.

Answer 4

Vous devriez regarder dans un outil appelé Powerdesigner. Vous pouvez télécharger un essai pleinement opérationnel de 15 jours. Cela vous aidera à modéliser, à garder les modifications à jour, etc.

C'est un excellent outil pour faire ce que vous demandez et bien plus encore.

Answer 5

Nous créons un répertoire pour chaque version dans notre référentiel de contrôle de version. Nous avons écrit un script qui lit les scripts de ce dossier et les exécute dans l'ordre du nom de fichier (nous écrivons donc des scripts portant des noms tels que 32.0.0_AddColumnXxxxyyyy). Ce format en pointillé nous permet d’insérer des scripts dans la séquence selon les besoins.

Lorsque nous mettons à jour un site, les nouveaux scripts sont détectés et exécutés. Cela présente un avantage par rapport à un outil comme SQL Compare (que j'aime beaucoup), car nous pouvons apporter des modifications ponctuelles aux données. Cependant, nous exécutons SQL Compare et SQL Data Compare (sur les tables sélectionnées) après la mise à jour pour garantir le bon fonctionnement de la procédure. Après une exécution réussie, toute l'opération est validée et la base de données met à jour les "scripts d'exécution". informations afin que ces scripts ne soient pas exécutés à nouveau.

L’avantage de le faire de cette façon est que nous ne pouvons pas "oublier". un script. De plus, lorsque nous essayons de passer à la base de données de tests ou de stockage intermédiaire, nous trouvons souvent des hypothèses cachées selon lesquelles les autres jeux de données sont désactivés avant d'atteindre la production.

Un autre avantage est que nous pouvons conserver diverses installations à différents niveaux de fonctionnalité pour différents clients. Cependant, lors de la mise à niveau, tous les scripts sont en place et prêts à être exécutés. Le seul problème que j’ai eu avec ce schéma est un "hors service" correctif appliqué à la base de données d'un utilisateur ... vous devez écrire vos scripts pour détecter que l'état d'origine est comme prévu et pour abandonner si ce n'est pas le cas.

Answer 6

Vous devriez probablement lire l’article écrit par Atwood sur le contrôle de version de la base de données sur le codage de l’horreur il y a quelque temps: Votre base de données est-elle sous contrôle de version?

Answer 7

Utilisez un outil tel que SQLCompare de RedGate ou un objet xSQL de xSQL Software pour générer vos scripts diff / delta T-SQL à la volée.

Vous pouvez même l'intégrer dans votre processus de construction si vous le souhaitez.

Pour différents clients disposant de bases de données différentes, vous disposez simplement de bases de données de référence différentes pour les comparer. Une fois que vous avez publié une mise à jour pour un client, vous mettez à jour votre propre site de référence avec le même script diff.

Voilà en quelques mots.

Answer 8

Je le fais à peu près de la même façon que vous. Je conserve un fichier Notes de publication de la base de données contenant toutes les modifications, les plus récentes figurant en haut de la liste avec le numéro de révision de subversion. Il contient également le code SQL qui a été exécuté pour appliquer cette modification.

En parallèle, je gère un modèle de base de données (j'utilise Clay Azzurri dans Eclipse) pour pouvoir régénérer mon modèle à tout moment. Toutes les modifications requises sont d'abord apportées au modèle, puis mises à jour. Azzurri ne peut pas générer d’ALTERations bien que CREATEs.

Tout cela est stocké sous subversion pour que je puisse revenir en arrière si nécessaire. Je devrais probablement garder une sorte de lien entre la révision svn de mon application et la révision de mon modèle.