Les bases de données multi-locataires ont-elles plusieurs bases de données ou tables partagées?
Est une base de données multi-locataire:
- Un serveur de base de données qui a une base de données/schéma différent (identique) pour chaque client/locataire ?; ou
- Un serveur de base de données qui a une base de données/schéma où les clients/locataires partagent des enregistrements à l'intérieur des mêmes tables?
Par exemple, sous l'option n ° 1 ci-dessus, je pourrais avoir un serveur MySQL à, disons, mydb01.example.com, et il pourrait avoir un customer1 base de données à l'intérieur. Cette customer1 la base de données pourrait avoir, disons, 10 tables qui alimentent mon application pour ce client particulier (Client # 1). Il peut également avoir un customer2 base de données contenant exactement les mêmes 10 tables, mais contenant uniquement des données pour le client n ° 2. Il pourrait avoir un customer3 base de données, un customer4 base de données, etc.
Dans l'option 2 ci-dessus, il n'y aurait qu'une seule base de données/schéma, par exemple, myapp_db, toujours avec 10 tableaux (les mêmes que ci-dessus). Mais ici, les données de tous les clients existent à l'intérieur de ces 10 tableaux, et ils "partagent" donc les tableaux. Et au niveau de la couche application, la logique et le contrôle de sécurité auxquels les clients ont accès à quels enregistrements dans ces 10 tables, et un grand soin est pris pour s'assurer que le client n ° 1 ne se connecte jamais à l'application et voit les données du client n ° 3, etc.
Lequel de ces paradigmes constitue une base de données "multi-tenant" traditionnelle? Et si non, alors quelqu'un peut-il me fournir un exemple (en utilisant les scénarios décrits ci-dessus) de ce qu'est une base de données multi-tenant?
Lequel de ces paradigmes constitue une base de données traditionnelle "multi-tenant"
Les deux concepts sont appelés multi-locataires, car il s'agit simplement d'un concept logique "dans lequel une seule instance de logiciel s'exécute sur un serveur et dessert plusieurs locataires" (de Wikipedia =). Mais la façon dont vous implémentez ce concept "physiquement" dépend de vous.
Bien sûr, l'application a besoin d'un concept de base de données qui permet de séparer les données des différents locataires, et l'idée de la multi-location est de partager certaines ressources du serveur (au moins le matériel) pour une meilleure utilisation des ressources et une administration plus facile. Ainsi, une "base de données multi-locataire" est celle qui prend cela directement en charge , où des parties du modèle ou des tables db sont partagées.
Pour être précis, il est possible de créer une application multi-locataire avec une base de données non multi-locataire, fournissant une instance de base de données individuelle par client. Cependant, cela empêche de partager toutes les ressources de base de données directement entre les locataires, et la couche application doit s'assurer de connecter le bon locataire à la bonne base de données.
Selon Microsoft, le terme a 3 significations potentielles (une base de données pour tous les locataires, ou un databaser par locataire).
Pour utiliser votre exemple, chaque client serait son propre locataire.
Une base de données par locataire (client)
- Chaque locataire est isolé des autres (pas d'accès accidentel aux données des autres locataires)
- L'isolement facilite également la gestion de la restauration des données ainsi que l'adaptation des besoins de stockage aux besoins des locataires.
Une base de données partagée, un schéma séparé.
- Chaque locataire a son propre schéma et leurs données sont dans leurs propres tables.
- La restauration peut prendre plus de temps, car tout le monde se trouve dans la même base de données, vous ne pouvez pas simplement restaurer la base de données dans une sauvegarde antérieure (elle annulerait les données de tous les locataires). Une option consiste à restaurer dans une nouvelle base de données, puis à fusionner/copier uniquement les données des 1 locataires.
Une base de données partagée, un schéma partagé.
- Les données de chaque locataire sont dans les mêmes tableaux. Si vous suivez les commandes par exemple, les commandes de chaque locataire se trouveront dans "dbo.Orders".
- Les données des locataires sont séparées par une colonne dans chaque table (peut être TenantId), qui indique le propriétaire de la ligne.
Il y a des avantages et des inconvénients pour chacun, bien expliqués dans cet article: https://msdn.Microsoft.com/en-us/library/aa479086.aspx
Bonus: vous pouvez le considérer comme un logement (grossièrement simplifié).
Chaque locataire a sa propre maison. Ils peuvent faire ce qu'ils veulent, et si ça brûle, cela n'affecte vraiment personne d'autre.
Chaque locataire est dans le même immeuble, mais a son propre appartement.
Tout le monde vit dans le même appartement et toutes les choses sont marquées d'un pense-bête pour montrer à qui il appartient.