web-dev-qa-db-fra.com

Multi-tenancy - base de données unique vs base de données multiple

Nous avons un certain nombre de clients, dont les systèmes partagent certaines fonctionnalités, mais ont également un certain degré de diversité. Le nombre de clients augmente - toujours une chose saine! - et la diversité entre leurs entreprises augmente également.

À l'heure actuelle, il existe un seul site Web ASP.Net (formulaires Web) (par opposition au projet Web), qui a des sous-dossiers pour chaque locataire, avec les pages non standard de ce locataire. Il existe un projet de modèle distinct, qui traite de l'accès aux bases de données et de la logique métier.

Ce qui est préférable - et surtout, pourquoi - entre avoir (a) 1 base de données par client, avec seulement les fonctionnalités associées à ce client; ou (b) une base de données unique partagée par tous les clients, où seul un sous-ensemble de tables est utilisé par un même client.

Les principales préoccupations au sein de l'entreprise sont dépassées:

  • maintenance de plusieurs actifs - sauvegardes, contrôle de version, etc.
  • promouvoir autant que possible la réutilisation

Comment garantiriez-vous que ces préoccupations soient prises en compte, quelle solution est préférable et pourquoi? (J'ai également compilé des réponses à des questions similaires)

database-designprojects-and-solutionsmultitenancy
20
RichardW1001

Voici les points saillants de la recherche provenant d'autres sources (à l'origine de révision 2 de la question ):

12
user40980

Si vous utilisez SQL Server, utilisez une base de données mais utilisez des schémas. Utilisez dbo pour les éléments généraux à tous les clients et créez un schéma pour chaque client et faites-en le schéma par défaut pour les utilisateurs de ce client. Vous pouvez maintenant avoir un objet général (par exemple un proc getBudget) dans le schéma dbo et un objet personnalisé pour le client dans leur schéma avec le même nom.

10
HLGEM

Étant donné que les bases de données et les fonctionnalités des clients divergent, cela signifie qu'à un moment donné, ils finiront par être des systèmes différents, donc dans ce cas, je recommanderais des systèmes distincts, car les coûts de maintenance des personnalisations pour chaque client l'emporteront sur les avantages d'un seul. système de base de données.

Les systèmes de base de données uniques conviennent mieux lorsque les changements entre différents clients ne sont que des configurations mais pas des fonctionnalités supplémentaires pour chaque client.

4
Stephen Senkomago Musoke

Vous manquez quelques inquiétudes. Les problèmes viendront avec la croissance. Si vous pouvez supposer qu'un jour vous deviendrez plus grand qu'un serveur DB - une base de données complexe vous causera certainement des maux de tête. À moins que vous n'investissiez à l'avance dans l'architecture. Mais c'est aussi une étape coûteuse)

N'oubliez donc pas qu'il est à la fois beaucoup moins cher et beaucoup plus facile de faire évoluer quelques bases de données différentes que d'énormes)

3
stim

Un problème que je n'ai pas vu abordé dans les réponses est le problème de la sécurisation correcte d'une application DB multi-locataire. Les applications multi-locataires doivent être conçues avec beaucoup de soin pour éviter les problèmes de sécurité. La plupart des bases de données et des applications fournissent une isolation, mais pas complète - il existe généralement des moyens d'inférer directement ou indirectement des données à travers les schémas de base de données. Et pas mal de ressources partagées (journaux et autres fichiers, tables DBA, curseurs ...) qui peuvent, à tout le moins, mener à des attaques de déni de service faciles sur d'autres locataires, et généralement beaucoup plus.

1
Egret