Dois-je utiliser un seul ou plusieurs bases de données de configuration pour une multi-application client?

Question

Je suis en train de travailler sur une application PHP qui a l'intention de soulager de la société de workflow et de gestion de projet, disons quelque chose comme Basecamp et GoPlan.

Je ne suis pas sûr de ce que la meilleure approche est la base de données sage. Dois-je utiliser une seule base de données et ajouter des clients-des colonnes spécifiques à chacune des tables, ou devrais-je créer une base de données pour chaque nouveau client? Un facteur important est l'automatisation: je veux qu'il soit mort simple de créer un nouveau client (et peut-être l'ouverture de la possibilité de s'inscrire par vous-même).

Possible contre je peux penser de l'utilisation d'une base de données:

• Manque d'extensibilité
• Des problèmes de sécurité (bien que les bugs ne devrait pas être là en premier lieu)

Quelles sont vos pensées sur cette question? Avez-vous des idées de ce que la solution ci-dessus les entreprises sont plus susceptibles d'avoir choisi?

Answer 1

J'ai l'habitude d'ajouter ClientID à toutes les tables et aller avec une base de données. Mais depuis la base de données est généralement difficile d'échelle, je vais aussi faire il possible pour s'exécuter sur différentes instances de base de données pour certains ou de tous les clients.

De cette façon, vous pouvez avoir un tas de petits clients dans une base de données et grands sur des serveurs distincts.

Un facteur clé pour la maintenabilité cependant, c'est que vous garder le schéma identique dans toutes les bases de données. Il y aura des maux de tête assez pour gérer le versioning sans introduire de client des schémas spécifiques.

Answer 2

Écouter la Stackoverflow podcast où Joel et Jeff parler de la même question. Joel est de parler de leur expérience en offrant une version hébergée de leur logiciel. Il souligne que l'ajout de l'id client sur votre DB complique la conception et le code (êtes-vous sûr que vous n'avez pas accidentellement oubliez pas de l'ajouter à certains clause where?) et complique l'hébergement de fonctionnalité, tels que les spécifiques au client à des sauvegardes.

C'était dans l'épisode #20 et #21 (vérifier les relevés de notes pour plus de détails).

Answer 3

De mon point de vue, cela dépendra de votre probable de la clientèle. Si vous pourriez être dans une situation où les rivaux sont à la fois à l'aide de votre système, alors vous serait mieux avec des bases de données distinctes. Elle dépend aussi de la façon dont plusieurs bases de données mise en œuvre par votre SGBD. Si chaque base de données possède une copie distincte de l'infrastructure, alors que suggère une seule base de données (ou d'un changement de SGBD). Si plusieurs bases de données peuvent être desservie que par un seul exemplaire de l'infrastructure, puis j'irais pour des bases de données distinctes.

Pense de sauvegarde de base de données. Le client A dit "s'il vous Plaît envoyez-moi une copie de mes données". Beaucoup, beaucoup plus facile dans une base de données distincte de l'installation que si une seule base de données est partagée. Pensez à la suppression d'un client; de nouveau, beaucoup plus facile avec des bases de données distinctes.

(Les "infrastructures" de la partie est farineuse gueule parce qu'il y a de grandes différences entre les différents SGBD sur ce qui constitue une "base de données" au lieu d'une instance de serveur", par exemple. Ajouter: La question est marqué 'mysql', donc peut-être que ces pensées ne sont pas complètement pertinent.)

Ajouter: Encore une question - avec plusieurs clients dans une seule base de données, chaque requête SQL est allez avoir besoin pour s'assurer que les données pour le bon client est choisi. Cela signifie que le SQL va être plus difficile à écrire, et lire, et le SGBD va avoir à travailler plus dur sur le traitement des données et les index sera plus grand, et ... je voudrais vraiment aller avec une base de données séparée par client pour de nombreuses fins.

Clairement, StackOverflow (par exemple) ne dispose pas d'une base de données séparée par utilisateur, nous utilisons tous la même base de données. Mais si vous étiez en cours d'exécution des systèmes de comptabilité pour entreprises différentes, je ne pense pas qu'il serait acceptable (pour les entreprises, et peut-être pas à la situation juridique des personnes) afin de partager des bases de données.

Answer 4

• DÉVELOPPEMENT Pour un développement rapide, l'utilisation d'une base de données par client. Pensez à quel point il est facile de sauvegarder, restaurer ou supprimer les données d'un client. Ou pour mesurer/suivre/le projet de loi consommation. Vous n'aurez pas besoin d'écrire le code pour le faire par vous-même, il suffit d'utiliser votre base de données primitives.

• PERFORMANCE Pour les performances, l'utilisation d'une base de données pour tous. Pensez au regroupement de connexions, de mémoire partagée, la mise en cache, etc.

• ENTREPRISE Si votre plan d'affaires est d'avoir beaucoup de petits clients (pensez hotmail), vous devriez probablement travailler sur un seul DB. Et de disposer de toutes les tâches administratives, telles l'enregistrement, la suppression, la migration des données, etc. entièrement automatisé et exposés dans une interface conviviale. Si vous prévoyez d'avoir des dizaines ou quelques centaines de clients, alors vous pouvez travailler dans une DB par client et que vous avez des scripts d'administration système en place qui peut être exploité par votre équipe de support clientèle.

Answer 5

Pour multilocataire, les performances augmentent généralement le plus de ressources, vous parvenez à partager entre locataires, voir

http://en.wikipedia.org/wiki/Multitenancy

Donc, si vous pouvez, allez-y avec la base de données unique. Je suis d'accord que les problèmes de sécurité ne pourrait se produire en raison de bugs, vous pouvez mettre en œuvre le contrôle d'accès dans l'application. Dans certaines bases de données, vous pouvez toujours utiliser la base de données de contrôle d'accès par prudence dans l'utilisation de vues (de sorte que chaque utilisateur authentifié obtient un point de vue différent).

Il y a des façons de fournir de l'extensibilité aussi. Par exemple, vous pouvez créer une seule table avec des attributs de l'extension (manipulés par le locataire, de base, et l'extension de l'attribut id). Ou vous pouvez créer par le locataire extension de tables, de sorte que chaque locataire a son propre extension de schéma.