Utilisation d'une base de données commune pour le développement collaboratif

Question

Certaines personnes de mon projet semblent penser qu’il est préférable d’utiliser une base de données de développement commune à tous les utilisateurs. Je pense que ce n’est pas le cas et que chaque développeur ayant sa propre base de données (avec des vidages de données actualisés périodiquement) est le meilleur. Ai-je raison ou tort? Avez-vous rencontré des problèmes avec l’une de ces approches?

Answer 1

L'espace disque et le processeur doivent être suffisamment économiques pour que chaque développeur puisse exécuter sa propre instance de la base de données , avec une génération automatisée sous contrôle de version. Cela est nécessaire pour permettre aux développeurs d’être audacieux dans le piratage de la base de données, indépendamment du piratage simultané de tout autre développeur.

La mise en garde étant, bien sûr, que toute modification apportée à leur instance privée est inutile pour quiconque à moins que ne puisse être appliquée automatiquement au cours du processus de construction. Il faut donc une politique ferme selon laquelle le code de l'application ne peut dépendre d'aucun état de la base de données, à moins que cet état ne soit représenté par des modifications contrôlées par la version et testées par l'unité de l'élément DDL .

Pour un excellent guide sur la théorie et la pratique consistant à traiter la définition de la base de données comme une autre partie du code du projet et à coordonner les modifications et les refactorings, voir Refactoring des bases de données: conception évolutive de la base de données par Scott W. Ambler et Pramod Sadalage.

Answer 2

J'aime disposer de ma propre copie de la base de données pour le développement, car elle vous donne la possibilité de changer rapidement les choses sans vous soucier des conséquences sur les autres.

Cependant, si tous les développeurs piratent leur propre copie de la base de données, il devient de plus en plus difficile de fusionner le travail de tout le monde à la fin.

Je pense que vous pouvez obtenir le meilleur des deux mondes en laissant les développeurs travailler sur une copie locale au cours du développement quotidien, mais chaque développeur devrait probablement fusionner son travail en une copie commune assez régulièrement. Écrire de nombreux tests unitaires est également utile.

Answer 3

Nous partageons une seule base de données parmi tous nos développeurs (une vingtaine) mais nous l'avons structurée de manière à ce que tout le monde ait ses propres tables.

Vous n'avez pas besoin d'une base de données séparée par développeur si vous structurez le droit de l'application. La base de données ou le préfixe de table qu’il utilise doit toujours être configurable afin que vous puissiez le déplacer facilement entre les instances (test unitaire, test du système, test de réception, production, récupération après sinistre, etc.).

L’utilisation d’une base de données unique présente l’avantage que le coût de la maintenance est amorti. Vos administrateurs de base de données n'essaient pas de gérer beaucoup de bases de données (ou, si vous êtes un petit magasin de base de données, tous les développeurs ne cherchent pas à maintenir leur propre base de données lorsqu'ils sont mieux utilisés en développement).

Answer 4

Avoir un seul point d'échec n'est pas une bonne chose, n'est-ce pas?

Answer 5

Je préfère une seule base de données partagée. Mais cela dépend beaucoup de la situation et des applications en cours de développement.

Ce qui fonctionne pour moi peut ne pas fonctionner pour vous. Allez avec vos tripes.

Answer 6

Si vous utilisez Hibernate ou une plate-forme basée sur hibernate, vous pouvez configurer la base de données pour qu'elle soit créée lorsque vous démarrez votre serveur (option de création / suppression). Ceci est très utile lorsque vous ajoutez de nouveaux attributs à vos classes. Si tel est le cas, chaque développeur doit disposer de sa propre copie de la base de données.

Si vous ne modifiez pas du tout la structure de la base de données, vous pouvez utiliser un seul DB partagé. Dans ce second cas, ce n'est pas un must. Je préfère avoir ma propre base de données où je peux faire ce que je veux. Cependant, rappelez-vous que certaines requêtes peuvent prendre beaucoup de temps et que cela affectera toute votre équipe si vous partagez une base de données.