Bases de données multiples V / s uniques
J'ai construit cette application web (php & mysql) qui stocke des informations pour diverses organisations (environ 20 clients actuellement).
Le scénario actuel stocke les informations relatives au client dans des bases de données individuelles. Il y a donc 20 bases de données clients et une base de données principale.
L'un des principaux avantages ici est que chaque base de données client étant isolée, la numérotation des artefacts client (rapports, audits), etc. est séquencée. donner à nos clients un sentiment de sécurité.
Chaque base de données contient environ 15 tables et la plupart des lignes d'une table datent d'environ 2000. On s'attend à ce que jusqu'à 5000 enregistrements soient remplacés, au maximum.
Gérer un seul changement au niveau de la base de données signifie changer 20 bases de données, mais dans les rares cas où je dois effectuer un tel changement, j'utilise un script qui le fait en un appel de fonction unique.
Nous sommes sur un arrangement d'hébergement partagé, et notre FAI nous fournit un non limité. de bases de données; et c'est ce qui m'a amené à penser en termes de centralisation de la base de données; de sorte que TOUTES les données client puissent être stockées dans la base de données master.
Bien sûr, certains problèmes importants qui se posent sont:
une. Maintenir la séquence d'artefacts (ceci pourrait être résolu en créant une clé de référence supplémentaire) b. Vitesse et performance (dans ce cas, je peux créer des index pour accélérer les choses) c. Sécurité: cela sera géré comme chaque requête qui récupère les informations du client. suivra également leur client_id
À l'avenir, nous devrons peut-être envisager de comparer les jeux de données d'une organisation avec ceux d'une autre, mais j'estime que cela peut également être réalisé sur une base de données centralisée. Je suis plutôt enclin (pour des raisons de performances et de maintenabilité) à passer à une base de données centralisée.
Pensez-vous que le passage à une base de données centralisée a plus de sens que de rester tel quel (sur des bases de données individuelles)?
Merci pour vos conseils.
Il y a des risques et des avantages hérités pour les deux systèmes. J'ai travaillé pour une société financière qui a soutenu environ 40 clients (banques nationales) sur une base de données. Nous avons ensuite acheté une autre société qui vendait un logiciel similaire et qui s’était dotée d’une base de données par client. Enfin, la société a fait faillite et nous avons dû exporter toutes les données des utilisateurs. Voici ce que les gens avec qui j'ai travaillé et que j'ai trouvé:
Pro's de Single DB:
- Les mises à jour logicielles et les corrections de bogues sont plus faciles.
- Facile à gérer et à rendre compte de toutes les données client.
- La mise à jour des données devient plus facile.
- Facile à créer une fonctionnalité modulaire que 1 client veut, désactivez-la pour les autres clients, puis activez-la quand ils le souhaitent dans le futur.
Con de Single DB:
- Intégrité des données - Nous avons eu 2 ou 3 cas où les utilisateurs d'une banque ont vu les données d'une autre banque. C'était un cauchemar. Surtout parce que les utilisateurs du site n'étaient pas seulement les employés de la banque, mais aussi les clients titulaires d'un compte bancaire! C'est de loin le plus gros problème avec 1 base de données
- Exporter des données client - Lorsque nous y sommes parvenus, ce n'était généralement pas un gros problème. Vous vous retrouvez avec 1 table qui contient tous les clients et vous en sortez pour obtenir les données spécifiques à votre client.
Pro de plusieurs DB:
- Il n'y a pas de problème de contamination croisée des données client ou de violation
- Exporter les données d'un client est extrêmement simple.
Con de plusieurs DB:
- Mises à jour et corrections de bugs - C'était le vrai cauchemar. Lorsque vous avez 20 clients sur 20 bases de données différentes, vous rencontrez rapidement le cas où un client souhaite la correction d'un bogue et qu'un autre pense que le bogue est une fonctionnalité ou ne veut pas risquer la mise à jour. De plus, vous aurez des cas où 1 client souhaite une amélioration de jeu mais les autres clients ne le souhaitent pas. Lorsque cela se produit, vos bases de données vont commencer à diverger. Du coup, vous devrez mettre à jour les clients 1-15 avec 1 script 16-19 avec un autre et 20 avec un troisième. Nous avons constaté que le problème était tel qu’une solution de bogue prendrait 15 à 20 fois plus de temps pour la société que nous achetions, car elle devait exécuter tous les tests pour chaque client et traiter le code spécial de chaque client. En réalité, ils avaient besoin d’une nouvelle personne de soutien pour chaque nouveau client, tandis que la société mère en avait besoin d’une pour tous les 5 à 10 clients.
- Gestion de la base de données - Lorsque vous rencontrez un grand nombre de clients, la gestion de toutes les bases de données devient un véritable problème. Vous aurez sans doute besoin de plus de temps DBA pour les gérer.
En fin de compte, ma recommandation après avoir vu et fait les deux est d'avoir de la "discipline"! Je pense que le choix multi-db est légèrement meilleur car il vous protège, mais vous ne pouvez jamais laisser vos clients faire un choix qui vous oblige à ajouter des fonctionnalités uniquement à eux, sinon vous vous frayerez un chemin vers l’échec.
J'aurais une base de données séparée pour des clients séparés. Un client peut le demander pour des raisons de sécurité - c’est-à-dire que seul son site a accès à ses données. Cela signifie également que si un client souhaite déplacer ses données, il sera beaucoup plus facile à gérer.
Cela signifie également que s'il y a un problème avec la base de données d'un client, cela n'affecte pas tous les autres.
Si vous souhaitez comparer des données entre clients, vous devez le faire séparément.
Si vous manquez de bases de données, vous devriez peut-être envisager de changer de fournisseur d’hôte.
Pour ajouter aux avantages/inconvénients énumérés jusqu'à présent:
Pro de plusieurs bases de données:
Les problèmes de verrouillage sont évités; Nous avons des bases de données où les clients peuvent déclencher des modifications DDL sur certaines des tables. Pour les tables plus grandes (> 2 m), cela verrouille la table pendant un temps considérable. Les seules personnes défavorisées sont leurs propres utilisateurs, ce qui est acceptable.
Flexibilité - certains clients ont des souhaits spécifiques concernant les données qu’ils souhaitent stocker; La multi-base de données nous a permis de modifier leur base de données de manière spécifique, sans avoir à encombrer le modèle de données pour les autres clients.
Les inconvénients:
- Major con: rejoindre sur d'autres tables est beaucoup plus lourd. Nous avons une base de données principale qui contient la plupart des méta-données. Les utilisateurs de la base de données spécifique au client n'ont pas accès à cette base de données. Par conséquent, toutes les jointures entre les tables de cette base de données et celle spécifique au client sont gérées dans l'application plutôt que dans la base de données. Vous pouvez résoudre ce problème en donnant aux utilisateurs spécifiques au client l'accès à la base de données principale, mais l'application pourrait/pourrait à nouveau divulguer des informations.
Bonne chance dans le choix!
Je sais que vous avez déjà choisi une réponse, mais il semble qu'il existe une autre solution qui n'a pas été suggérée:
Déplacez tout dans une base de données, mais créez des tables pour chaque client, en utilisant un préfixe, comme ceci:
initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl
C'est un peu le meilleur des deux mondes.
- Il est très facile de migrer de votre configuration actuelle vers la nouvelle configuration.
- Vous pouvez créer 1 utilisateur par client et limiter ses privilèges aux tables de sa société et rien d'autre
- Vous pouvez créer un superutilisateur et regrouper facilement des données si vous en avez besoin.
- Utilisez une seule base de données
La seule raison pour laquelle je n'aurais pas de base de données individuelle pour chaque client est si vous avez des centaines ou des milliers de clients/bases de données. Cela pourrait devenir très difficile à gérer, notamment en apportant des modifications à la base de données ou en faisant quelque chose dans toutes les bases de données. Les actions effectuées sur un grand nombre de bases de données multiples peuvent également être lentes car vous devez ouvrir (et donc fermer) autant de tables.
Mais en dehors de ce cas, je pense que plusieurs bases de données est préférable.
Un avantage, qui peut ne pas être important mais utile, est que chaque client obtient ses propres ID séquentiels (au lieu de sauter un paquet parce qu'un autre client a ajouté des enregistrements).
En outre, plusieurs bases de données permettent de personnaliser facilement les sous-tables (comme le type de téléphone) par client sans avoir besoin d'un identifiant d'enregistrement parent dans ces tables.
D'abord la séquence d'artefacts. Je suppose que vous utilisez des clés primaires entières pour fournir cela. Vraiment, vous devriez avoir une colonne séparée "numéro d'artefact". Les PK devraient être des PK et rien d'autre. Les gens parlent de "clés naturelles", etc., et je grince des dents. Chaque fois que vous comptez sur la PC pour être plus qu'un identifiant, elle revient vous mordre. Si vous voulez connaître la séquence de quelque chose, enregistrez une date ou un numéro de séquence.
Je pense que dans votre cas, la gestion de la configuration vous mènerait à une base de données unique. Regardez ce qu'il vous en coûte à temps pour maintenir et mettre à niveau les bases de données. Quels coûts sont associés à chaque version du logiciel? Pensez également au coût lorsque vous obtenez un nouveau client et devez créer une base de données et configurer l'application pour cela. Tout peut être automatisé, la question est de savoir si cela en vaut la peine si vous avez 100 bases de données.
À l'avenir, il est plus facile de mettre à l'échelle (base de données, partitionnement, matériel, etc.) une base de données unique que de faire la même chose pour 100 bases de données.
Je pense que les autres affiches ont présenté d'excellents arguments, je ne les passerai donc pas en revue.