SaaS: une application web vers une base de données VS. De nombreuses applications Web à de nombreuses bases de données

Question

Je prévois de développer un service SaaS assez petit. Chaque client professionnel aura une base de données associée (même schéma dans les bases de données des clients, données différentes). De plus, ils auront un domaine unique pointant vers l'application web, et ici je vois ces 2 options:

1. Les domaines pointera vers une application web unique, qui va changer la chaîne de connexion chez le bon client base de données en fonction du domaine . (C'est-à-dire, je devrai déployer une seule application Web.)
2. Les domaines pointeront vers leur propre application web, qui est vraiment la même application web répliquée pour chaque client mais avec la bonne chaîne de connexion au client base de données. (C'est, je dois déployer de nombreuses applications Web.)

Ceci est pour une application Web ASP.NET 4.0 MVC 3.0 qui fonctionnera sur IIS 7.0. Ce sera assez petit, mais j'ai besoin d'être évolutif. Dois-je aller avec 1 ou 2?

Answer 1

This MSDN article est une grande ressource qui va dans le détail sur les avantages de trois modèles:

1. Séparé DB. Chaque instance d'application possède sa propre instance de base de données. Plus facile, mais peut être difficile à administrer du point de vue de l'infrastructure de base de données.
2. Schéma séparé. Chaque instance d'application partage une base de données mais est partitionnée via des schémas. Nécessite un peu plus de travail de codage, et atténue certains des défis d'un schéma totalement séparé, mais a encore des difficultés si vous avez besoin de sauvegarde/restauration de site individuel et des choses comme ça.
3. Schéma partagé. Votre application est responsable du partitionnement des données en fonction de l'instance de l'application. Cela nécessite le plus de travail, mais est le plus flexible en termes de gestion des données.

Pour ce qui est de la façon dont votre application le gère, la conception de base de données le déterminera probablement. J'ai déjà fait à la fois DB partagé et schéma partagé. Dans l'approche DB séparée, je sépare également les instances d'application. Dans l'approche de schéma partagé, c'est la même application avec logique pour modifier les données disponibles en fonction de la connexion et/ou du nom d'hôte.

Answer 2

Je ne suis pas sûr que ce soit la réponse que vous cherchez, mais il y a une troisième option:

En utilisant un modèle de base de données multi-locataires. Une base de données unique qui prend en charge tous les clients. Vos tables contiendraient des clés primaires composites.

Éteignez lorsque vous en avez besoin. Si votre service est petit, je ne verrais aucun avantage pour plusieurs bases de données, sauf pour assurer la sécurité des données, ce qui signifie que vous ne ramènerez les résultats de la requête que pour le bon client. Les coûts seront beaucoup plus élevés en utilisant plusieurs bases de données si vous prévoyez d'héberger avec un service cloud. Si SalesForce peut héberger leur SaaS en utilisant une conception à plusieurs destinataires, je considérerais au moins cela comme une option viable pour un petit service.