Bases de données multiples V / s simples

J'ai construit cette application web (php et 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 client et 1 base de données master.

L'un des principaux avantages ici est que, comme chaque base de données client est isolée, la numérotation des artefacts clients (rapports, audits), etc. est séquencée; donner à nos clients un sentiment de sécurité.

Chaque base de données possède environ 15 tables, et le plus grand nombre de lignes dans une table est d'environ 2000. Cela devrait être augmenté jusqu'à 5 000 enregistrements, au maximum.

La gestion d'une seule modification au niveau de la base de données signifie la modification de 20 bases de données, mais dans les rares cas où je dois effectuer une telle modification, j'utilise un script qui le fait en un seul appel de fonction.

Nous sommes sur un arrangement d'hébergement partagé, et notre FAI nous fournit un nombre limité. des bases de données; et c'est ce qui m'a amené à penser en termes de centralisation de la base de données; afin 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 surgissent sont:

une. Maintenir la séquence des artefacts (cela pourrait être résolu en créant une clé de référence supplémentaire) b. Vitesse et performances (auquel 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 client. suivra également leur client_id

À l'avenir, nous devrons peut-être envisager de comparer les ensembles de données d'une organisation à une autre, mais je pense que cela peut également être réalisé sur une base de données centralisée. Je suis quelque peu enclin (pour des raisons de performances et de maintenabilité) à passer à une base de données centralisée.

Pensez-vous que passer à une base de données centralisée est plus logique que de rester tel que nous sommes (sur des bases de données individuelles)?

Merci pour vos conseils.

Il existe des risques et des avantages hérités pour les deux systèmes. J'ai travaillé pour une société financière qui a accompagné environ 40 clients (banques nationales) sur 1 base de données. Nous avons ensuite acheté une autre entreprise qui vendait des logiciels similaires et qui était allée avec 1 base de données par client. Enfin, l'entreprise 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é:

Avantages de Single DB:

1. Les mises à jour logicielles et les corrections de bogues sont plus faciles.
2. Facile à gérer et à générer des rapports sur toutes les données client.
3. La mise à jour des données devient plus facile.
4. Facile à créer une fonctionnalité modulaire souhaitée par 1 client, désactivez-la pour les autres clients, puis désactivez-la quand ils le souhaitent à l'avenir.

Les inconvénients de Single DB:

1. 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. Ce fut un cauchemar. Surtout parce que les utilisateurs du site n'étaient pas seulement les employés de la banque, mais les véritables clients de la banque! C'est de loin le plus gros problème avec 1 base de données
2. Exporter les données des clients -Lorsque nous y étions confrontés, ce n'était généralement pas un gros problème. Vous vous retrouvez avec 1 table qui contient tous les clients et vous vous déconnectez de cette table pour obtenir les données spécifiques de votre client.

Avantages de plusieurs bases de données:

1. Il n'y a aucun problème de contamination ou de violation de données entre clients
2. Exporter les données d'un client est très simple.

Les inconvénients de plusieurs bases de données:

1. Mises à jour et corrections de bugs - Ce fut le vrai cauchemar. Lorsque vous avez 20 clients sur 20 bases de données différentes, vous rencontrez rapidement le cas où 1 client souhaite un bug corrigé et un autre pense que le bug est une fonctionnalité ou ne veut pas risquer la mise à jour. De plus, vous aurez des cas où 1 client souhaite une amélioration du jeu mais pas les autres clients. Lorsque cela se produit, vos bases de données commencent à diverger. Soudain, vous devrez mettre à jour les clients 1-15 avec 1 script 16-19 avec un autre et 20 avec un troisième. Nous avons vu que cela devenait un problème tel qu'une correction de bogue prenait 15 à 20 fois plus de temps pour l'entreprise que nous avions achetée que pour nous, car ils devaient exécuter tous les tests pour chaque client et gérer le code spécial de chaque client. En effet, ils avaient besoin d'une nouvelle personne de soutien pour chaque nouveau client,
2. Gestion des bases de données - Lorsque vous accédez à un grand nombre de clients, la gestion de toutes les bases de données devient un véritable problème. Vous aurez sans aucun doute besoin de plus de temps DBA pour les gérer.

Au final ma recommandation après avoir vu et fait les deux c'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 ou vous vous mettrez sur la voie de l'échec.

J'aurais une base de données distincte pour des clients distincts. Un client peut l'exiger 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, cela 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 les données entre les clients, vous devez le faire séparément.

Si vous manquez de bases de données que vous pouvez avoir, vous devriez peut-être envisager de changer de fournisseur d'hébergement.

La seule raison pour laquelle je n'aurais pas de base de données individuelle pour chaque client est si vous allez avoir des centaines ou des milliers de clients / bases de données. Cela pourrait devenir très difficile à gérer, y compris apporter des modifications à la base de données ou faire quelque chose dans toutes les bases de données. Les actions qui se produisent 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 à part ce cas, je pense que plusieurs bases de données sont meilleures.

Un avantage, qui peut ne pas être important mais peut être utile, est que chaque client obtient ses propres ID séquentiels (au lieu de sauter éventuellement un groupe car un autre client a ajouté des enregistrements).

De plus, plusieurs bases de données permettent aux sous-tables (comme le type de téléphone) d'être facilement personnalisables par client sans avoir besoin d'un ID d'enregistrement parent dans ces tables également.

D'abord le séquençage des artefacts. Je suppose que vous utilisez des clés primaires entières pour fournir cela. Vraiment, vous devriez avoir une colonne "numéro d'artefact" séparée. Les PK devraient être des PK et rien d'autre. Les gens parlent de "clés naturelles" et autres et je grince des dents. Chaque fois que vous comptez sur le PK pour être plus qu'un identifiant, il 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 conduirait à une seule base de données. Regardez ce qu'il vous en coûte à temps pour maintenir et mettre à niveau les bases de données. Quels sont les coûts 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 vaudra la peine lorsque vous aurez 100 bases de données?

En fin de compte, il est plus facile de faire évoluer (partitionnement, matériel, partitionnement, etc.) une seule base de données que de faire de même pour 100 bases de données.

Je pense que les autres affiches ont fait quelques excellents points donc je ne vais pas les passer en revue.

Pour ajouter aux avantages et aux inconvénients répertoriés jusqu'à présent:

Avantages de plusieurs bases de données:

1. 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 tables. Pour les tables plus grandes (> 2 m d'enregistrements), cela verrouille la table pendant une durée considérable. Les seules personnes désavantagées sont leurs propres utilisateurs, c'est donc en quelque sorte acceptable.

2. Flexibilité - certains clients ont des souhaits spécifiques concernant les données qu'ils souhaitent stocker; multi-base de données nous a permis de modifier spécifiquement leur base de données, sans avoir à encombrer le modèle de données pour les autres clients.

Les inconvénients:

1. Con majeur: se joindre à d'autres tables est beaucoup plus lourd. Nous avons une base de données principale qui contient la plupart des métadonnées. Les utilisateurs de la base de données spécifiques au client n'ont pas accès à cette base de données, donc toutes les jointures entre les tables de cette base de données et celles spécifiques 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 alors à 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 y ait 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 en quelque sorte 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 restreindre ses privilèges aux tables de son entreprise et rien d'autre
• Vous pouvez créer un superutilisateur et agréger facilement les données si vous en avez besoin.
• Utiliser une seule base de données