2009-09-18 5 views
1

Si je construis une application Web CRM à vendre en tant que service d'adhésion, quelle est la meilleure méthode pour concevoir et déployer la base de données? Est-ce que j'ai une base de données qui contient 100s d'enregistrements par table ou déploie plusieurs bases de données pour différents clients?Logiciel en tant que service - Base de données

Est-ce vraiment un problème d'utiliser une seule base de données puisque je crois que des sites comme Flickr les utilisent?

+0

Curieux, qu'offrirez-vous que salesforce.com ne possède pas déjà? – JeffO

+0

juste un scénario hypothétique – Theo

Répondre

6

Plusieurs clients sont appelés "multi-locataires". Voir par exemple cet article "Multi-Tenant Data Architecture" de Microsoft.

+0

@Theo: pourquoi ne pas concevoir votre système pour fonctionner dans les deux configurations: 1) bases de données différentes et 2) même base de données, mais différents schémas. Fondamentalement, votre application client obtient une connexion db pour un client de manière générique et fonctionne uniquement avec la base de données. Dans ce cas, vous pouvez configurer votre déploiement et également passer de l'un à l'autre si nécessaire. – van

+0

@van: Je viens de lire l'article sur Multi-Tenant Data Architecture, très instructif. Votre commentaire a du sens, c'est juste que la méthode du schéma différent est apparemment un peu de travail pour restaurer les sauvegardes par schéma. Bien que le principal avantage de l'option de schéma soit la possibilité pour MS SQL de gérer plus de déploiements. Des choix difficiles à faire ici – Theo

+0

@chrisW: Après avoir lu cet article, tout se résume au scénario dans lequel l'application SaaS est construite et aux implications de sécurité. Pour ma situation actuelle cependant, l'option intensive intensive semble le choix le plus logique permettant une évolutivité indépendante par client sans la zone grise que l'option schema apporte. – Theo

0

À long terme, il est plus facile de gérer une base de données contenant plusieurs données de clients. Pensez au déploiement, à la sauvegarde, etc. Cependant, cela ne vous empêche pas d'avoir plusieurs instances de cette base de données, chacune contenant un sous-ensemble de l'ensemble de données client complet. Je recommande d'augmenter le nombre de bases de données après avoir établi l'utilité/la désirabilité de votre produit. Je n'ai pas besoin d'une infrastructure complexe si vous n'avez pas de trafic ...

Donc, je mettrais juste un identifiant de client dans les tables appropriées et sourirais quand le client 4 arrivera et l'étendue de votre nouveau déploiement est d'un insert déclaration.

3

Dans une situation comme un système CRM, vous aurez probablement besoin d'avoir des instances distinctes de votre base de données pour chaque client. Je dis cela parce que si vous souhaitez des clients plus importants, la plupart des entreprises ont mis en place des politiques de sécurité concernant les données clients. Si vous stockez les données de vos clients dans la même base de données qu'un autre client, vous courez le risque d'exposer des données confidentielles d'une entreprise à une autre société (un concurrent, etc.).

Des sites comme Flickr n'ont pas à s'inquiéter autant car la plupart d'entre nous sur Interwebs n'ont pas de politique stricte concernant nos données personnelles.

+0

+1 pour des raisons de sécurité. Dans le monde CRM, on avait l'habitude de penser que les solutions hébergées n'étaient même pas possibles en raison de problèmes de sécurité. Cependant salesforce.com s'est trompé, mais ils font de leur mieux pour prouver à leurs clients que leurs données sont sécurisées. vous devez avoir plus d'automatisation pour plusieurs sauvegardes de base de données, etc. Mais il est également plus facile de migrer/d'étendre les données des clients et de les mettre à jour vers les nouvelles structures de base de données une par une. – van

+0

Oui, en effet, c'est vrai. Nous avons même des clients qui ne nous permettent pas de stocker des données sur le même serveur dans une base de données différente et qui ont même fait que le serveur soit dans un bâtiment différent. Nous avons également eu un incident très embarrassant il y a environ trois ans lorsqu'un développeur a oublié de mettre l'identifiant du client dans une requête et d'envoyer des données propriétaires par email aux commerciaux de plusieurs autres sociétés qui étaient dans la même base de données.Croyez-moi tous nos grands clients sont sur des systèmes séparés maintenant. – HLGEM

+0

... d'autre part, avec de nombreux petits clients qui utilisent beaucoup votre système simultanément, vous pourriez avoir des problèmes avec le pool de connexion. – van

Questions connexes