Bases de données multiples contre base de données unique avec des données partitionnées logiquement

Vous regretterez d'avoir utilisé des bases de données distinctes :

• Si jamais vous souhaitez accorder des autorisations aux bases de données elles-mêmes aux clients ou aux superutilisateurs.
• Si jamais vous souhaitez restaurer la base de données d'un seul client sans affecter les données des autres.
• S'il existe des préoccupations réglementaires concernant vos données et les violations de données, et que vous découvrez tardivement que ces réglementations ne peuvent être respectées qu'en disposant de bases de données distinctes. (Mise à jour :un peu plus de 4 ans après la rédaction de cette réponse, le RGPD est entré en vigueur)
• Si vous souhaitez déplacer facilement les données de vos clients vers plusieurs serveurs de base de données ou autrement évoluer, ou déplacer des clients plus importants/plus importants vers un matériel différent. Dans une autre partie du monde.
• Si vous souhaitez archiver et désaffecter facilement les anciennes données client.
• Si vos clients se soucient du cloisonnement de leurs données et qu'ils découvrent que vous avez agi autrement.
• Si vos données font l'objet d'une assignation à comparaître et qu'il est difficile d'extraire les données d'un seul client, ou si l'assignation est trop large et que vous devez produire l'intégralité de la base de données au lieu de se limiter aux données d'un seul client.
• Lorsque vous oubliez de rester vigilant et qu'une seule requête passe sans inclure AND CustomerID = @CustomerID . Astuce :utilisez un outil d'autorisations scripté ou des schémas, ou encapsulez toutes les tables avec des vues qui incluent WHERE CustomerID = SomeUserReturningFunction() , ou une combinaison de ceux-ci.
• Lorsque vous obtenez des autorisations erronées au niveau de l'application et que les données client sont exposées au mauvais client.
• Lorsque vous souhaitez disposer de différents niveaux de protection de sauvegarde et de restauration pour différents clients.
• Une fois que vous réalisez que la création d'une infrastructure pour créer, provisionner, configurer, déployer et faire tourner de nouvelles bases de données vaut l'investissement, car cela vous oblige à vous perfectionner.
• Lorsque vous n'autorisiez pas la possibilité qu'une catégorie de personnes ait besoin d'accéder aux données de plusieurs clients et que vous ayez besoin d'une couche d'abstraction au-dessus de Customer car WHERE CustomerID = @CustomerID ne le coupera pas maintenant.
• Lorsque des pirates informatiques ciblent vos sites ou systèmes et que vous leur avez permis d'obtenir facilement toutes les données de tous vos clients d'un seul coup après avoir obtenu les informations d'identification d'administrateur en seulement une base de données.
• Lorsque la sauvegarde de votre base de données prend 5 heures à s'exécuter, puis échoue.
• Lorsque vous devez obtenir l'édition Enterprise de votre SGBD afin de pouvoir effectuer des sauvegardes compressées afin que la copie du fichier de sauvegarde sur le réseau prenne moins de 5 heures plus .
• Lorsque vous devez restaurer l'intégralité de la base de données tous les jours sur un serveur de test, ce qui prend 5 heures, et exécuter des scripts de validation qui prennent 2 heures.
• Lorsque seuls quelques-uns de vos clients ont besoin d'une réplication et que vous devez l'appliquer à tous vos clients plutôt qu'à ces quelques-uns.
• Lorsque vous souhaitez prendre en charge un client gouvernemental et que vous découvrez qu'il vous demande d'utiliser un serveur et une base de données distincts, mais que votre écosystème a été construit autour d'un serveur et d'une base de données uniques et que le changement est trop difficile ou prendra trop de temps .

Vous serez ravi d'avoir utilisé des bases de données distinctes :

• Lorsqu'un déploiement pilote auprès d'un client explose complètement et que les 999 autres clients ne sont absolument pas affectés. Et vous pouvez restaurer à partir d'une sauvegarde pour résoudre le problème.
• Lorsque l'une de vos sauvegardes de base de données échoue et que vous ne pouvez réparer qu'une seule en 25 minutes au lieu de recommencer tout le processus de 10 heures.

Vous regretterez d'avoir utilisé une seule base de données :

• Lorsque vous découvrez un bogue qui affecte les 1 000 clients et qu'il est difficile de déployer le correctif sur 1 000 bases de données.
• Lorsque vous obtenez des autorisations erronées au niveau de la base de données et que les données client sont exposées au mauvais client.
• Lorsque vous n'autorisiez pas la possibilité qu'une catégorie de personnes ait besoin d'accéder à un sous-ensemble de toutes les bases de données (peut-être que deux clients fusionnent).
• Quand vous ne pensiez pas à quel point il serait difficile de fusionner deux bases de données de données différentes.
• Lorsque vous avez fusionné deux bases de données de données différentes et que vous réalisez que l'une d'entre elles n'était pas la bonne, et que vous n'avez pas prévu de vous remettre de ce scénario.
• Lorsque vous essayez de dépasser 32 767 clients/bases de données sur un seul serveur et que vous découvrez qu'il s'agit du maximum dans SQL Server 2012.
• Lorsque vous réalisez que la gestion de plus de 1 000 bases de données est un cauchemar bien plus important que vous ne l'auriez jamais imaginé.
• Lorsque vous réalisez que vous ne pouvez pas intégrer un nouveau client simplement en ajoutant des données dans un tableau, et que vous devez exécuter un tas de scripts effrayants et compliqués pour créer, remplir et définir des autorisations sur une nouvelle base de données.
• Lorsque vous devez exécuter 1 000 sauvegardes de base de données chaque jour, assurez-vous qu'elles réussissent toutes, copiez-les sur le réseau, restaurez-les toutes dans une base de données de test et exécutez des scripts de validation sur chacune d'entre elles, en signalant tout échec d'une manière qui seront garantis d'être vus, et qui sont facilement et rapidement actionnables. Et puis 150 d'entre eux échouent à divers endroits et doivent être réparés un par un.
• Lorsque vous découvrez que vous devez configurer la réplication pour 1 000 bases de données.

Ce n'est pas parce que j'ai énuméré plus de raisons pour une que c'est mieux.

Certains lecteurs peuvent tirer profit de MSDN :Multi - Architecture des données des locataires . Ou peut-être Modèles de conception d'applications de location SaaS . Ou même Développement multi-tenant Applications pour le cloud, 3e édition