Quels sont les avantages d’utiliser une seule base de données pour CHAQUE client ?

Question

Dans une application centrée sur une base de données conçue pour plusieurs clients, j'ai toujours pensé qu'il était « préférable » d'utiliser une seule base de données pour TOUS les clients – en associant les enregistrements aux index et clés appropriés.En écoutant le podcast Stack Overflow, j'ai entendu Joel mentionner que FogBugz utilise une base de données par client (donc s'il y avait 1 000 clients, il y aurait 1 000 bases de données).Quels sont les avantages d’utiliser cette architecture ?

Je comprends que pour certains projets, les clients ont besoin d'un accès direct à toutes leurs données. Dans une telle application, il est évident que chaque client a besoin de sa propre base de données.Cependant, pour les projets où un client n'a pas besoin d'accéder directement à la base de données, y a-t-il des avantages à utiliser une base de données par client ?Il semble qu'en termes de flexibilité, il soit beaucoup plus simple d'utiliser une seule base de données avec une seule copie des tables.Il est plus facile d'ajouter de nouvelles fonctionnalités, il est plus facile de créer des rapports et c'est tout simplement plus facile à gérer.

J'étais assez confiant dans la méthode "une base de données pour tous les clients" jusqu'à ce que j'entende Joel (un développeur expérimenté) mentionner que son logiciel utilise une approche différente - et je suis un peu confus avec sa décision...

J'ai entendu des gens dire que les bases de données ralentissent avec un grand nombre d'enregistrements, mais toute base de données relationnelle présentant un certain mérite n'aura pas ce problème - surtout si des index et des clés appropriés sont utilisés.

Toute contribution est grandement appréciée !

Answer 1

Supposons qu'il n'y ait aucune pénalité de mise à l'échelle pour stocker tous les clients dans une seule base de données ;pour la plupart des gens et des bases de données/requêtes bien configurées, cela sera assez vrai de nos jours.Si vous n’êtes pas l’une de ces personnes, l’avantage d’une base de données unique est évident.

Dans cette situation, les avantages proviennent de l’encapsulation de chaque client.Du point de vue du code, chaque client existe de manière isolée : il n'existe aucune situation possible dans laquelle une mise à jour de la base de données pourrait écraser, corrompre, récupérer ou modifier des données appartenant à un autre client.Cela simplifie également le modèle, car vous n'avez jamais besoin de considérer le fait que les enregistrements peuvent appartenir à un autre client.

Vous bénéficiez également des avantages de la séparabilité : il est trivial d'extraire les données associées à un client donné et de les déplacer vers un autre serveur.Ou restaurez une sauvegarde de ce client lorsque vous appelez pour dire « Nous avons supprimé certaines données clés ! », en utilisant les mécanismes de base de données intégrés.

Vous bénéficiez d'une mobilité de serveur simple et gratuite : si vous dépassez la taille d'un serveur de base de données, vous pouvez simplement héberger de nouveaux clients sur un autre serveur.S'ils étaient tous dans une seule base de données, vous auriez besoin soit d'un matériel plus puissant, soit d'exécuter la base de données sur plusieurs machines.

Vous bénéficiez d'une gestion des versions facile - si un client souhaite conserver la version 1.0 du logiciel et qu'un autre souhaite la version 2.0, où 1.0 et 2.0 utilisent des schémas de base de données différents, il n'y a pas de problème - vous pouvez en migrer un sans avoir à les retirer d'une base de données.

Je peux penser à quelques dizaines d’autres, je suppose.Mais dans l’ensemble, le concept clé est la « simplicité ».Le produit gère un client, et donc une base de données.Il n'y a jamais de complexité liée au problème "Mais la base de données contient également d'autres clients".Cela correspond au modèle mental de l’utilisateur, où il existe seul.Les avantages, comme la possibilité de créer facilement des rapports sur tous les clients en même temps, sont minimes : à quelle fréquence souhaitez-vous un rapport sur le monde entier, plutôt que sur un seul client ?

Answer 2

Voici une approche que j'ai déjà vue :

• Chaque client dispose d'une chaîne de connexion unique stockée dans une base de données client principale.
• La base de données est conçue de manière à ce que tout soit segmenté par CustomerID, même s'il n'y a qu'un seul client dans une base de données.
• Des scripts sont créés pour migrer toutes les données client vers une nouvelle base de données si nécessaire, et seule la chaîne de connexion de ce client doit être mise à jour pour pointer vers le nouvel emplacement.

Cela permet d'utiliser une seule base de données au début, puis de la segmenter facilement plus tard une fois que vous avez un grand nombre de clients, ou plus communément lorsque vous avez quelques clients qui abusent du système.

J'ai constaté qu'il est très difficile de restaurer des données client spécifiques lorsque toutes les données se trouvent dans la même base de données, mais la gestion des mises à niveau est beaucoup plus simple.

Lorsque vous utilisez une seule base de données par client, vous rencontrez un énorme problème consistant à maintenir tous les clients fonctionnant avec la même version de schéma, et cela ne prend même pas en compte les tâches de sauvegarde sur tout un ensemble de bases de données spécifiques au client.Naturellement, la restauration des données est plus facile, mais si vous veillez à ne pas supprimer définitivement les enregistrements (il suffit de les marquer avec un indicateur supprimé ou de les déplacer vers une table d'archive), vous aurez alors moins besoin de restaurer la base de données en premier lieu.

Answer 3

Pour faire simple.Vous pouvez être sûr que votre client ne voit que ses données.Le client qui possède moins d'enregistrements n'a pas à payer la pénalité de devoir rivaliser avec des centaines de milliers d'enregistrements qui peuvent se trouver dans la base de données mais pas dans les siens.Peu m'importe à quel point tout est indexé et optimisé, il y aura des requêtes qui détermineront qu'elles doivent analyser chaque enregistrement.

Answer 4

Eh bien, que se passe-t-il si l'un de vos clients vous demande de restaurer une version antérieure de ses données en raison d'un travail d'importation bâclé ou similaire ?Imaginez ce que ressentiraient vos clients si vous leur disiez « vous ne pouvez pas faire ça, puisque vos données sont partagées entre tous nos clients » ou « Désolé, mais vos modifications ont été perdues car le client X a demandé une restauration de la base de données ».

Answer 5

Quant à la difficulté de mettre à niveau 1 000 serveurs de bases de données à la fois, une automatisation assez simple devrait s'en occuper.Tant que chaque base de données conserve un schéma identique, cela ne posera pas vraiment de problème.Nous utilisons également l’approche base de données par client, et cela fonctionne bien pour nous.

Voici un article sur ce sujet précis (oui, c'est MSDN, mais c'est un article indépendant de la technologie) : http://msdn.microsoft.com/en-us/library/aa479086.aspx.

Une autre discussion sur la multilocation en ce qui concerne votre modèle de données ici : http://www.ayende.com/Blog/archive/2008/08/07/Multi-Tenancy--The-Physical-Data-Model.aspx

Answer 6

Évolutivité.Sécurité.Notre société utilise également 1 base de données par approche client.Cela rend également le code un peu plus facile à maintenir.

Answer 7

J'ajoute simplement cette réponse pour inclure le mot multi-locataire ici.Je cherchais ceci, en utilisant "multitenant" comme requête, et celle-ci n'apparaissait pas.

Answer 8

Merci pour votre contribution - tous des points excellents et très valables.Je suppose que je recherche davantage la flexibilité de la mise à niveau.Si vous devez modifier le schéma pour ajouter une nouvelle fonctionnalité (disons pour une application Web) ou pour améliorer des fonctionnalités existantes, c'est simple à faire dans une seule base de données.Si vous deviez répliquer cette modification sur 1 000 bases de données distinctes, le risque d’erreur augmente.Que se passe-t-il si une opération échoue ?Combien de temps faut-il pour mettre à niveau chaque client ?

Si des sauvegardes appropriées sont conservées (ou si votre base de données a été structurée de manière à ce que les données n'aient jamais été écrasées), la restauration des données d'un client particulier est triviale.

La simplicité du code, bien qu’importante, ne devient pas vraiment extrêmement compliquée.Selon le langage utilisé et les méthodologies, il est simple de créer des objets qui représentent uniquement ce client spécifique (qui stocke un ID client particulier) et le reste du projet ne doit être codé que pour un seul objet (un peu comme un seul client). ).

L'évolutivité est un élément à prendre en compte - vous avez raison, il est facile de prendre une seule base de données isolée et de la déplacer vers un autre serveur physique ;cependant, il devient de plus en plus facile de regrouper des serveurs - et même sans clustering, il semble que ce serait un petit changement de pointer chaque client vers un SERVEUR de base de données qui héberge la base de données universelle (vous pourriez donc avoir deux ou trois serveurs de base de données hébergeant une seule base de données chacun, par exemple).Cette approche limite le processus de mise à niveau à seulement trois bases de données.

Answer 9

Dans les secteurs réglementés tels que les soins de santé, il peut être nécessaire d'avoir une base de données par client, voire même un serveur de base de données distinct.

La réponse simple à la mise à jour de plusieurs bases de données lors d'une mise à niveau consiste à effectuer la mise à niveau en tant que transaction et à prendre un instantané avant la mise à niveau si nécessaire.Si vous exécutez correctement vos opérations, vous devriez pouvoir appliquer la mise à niveau à n'importe quel nombre de bases de données.

Le clustering n'est pas vraiment une solution au problème des index et des analyses de tables complètes.Si vous passez à un cluster, très peu de changements.Si vous disposez de nombreuses bases de données plus petites à distribuer sur plusieurs machines, vous pouvez le faire à moindre coût sans cluster.La fiabilité et la disponibilité sont des considérations mais peuvent être traitées d'autres manières (certaines personnes auront toujours besoin d'un cluster, mais la majorité n'en aura probablement pas besoin).

J'aimerais avoir un peu plus de contexte de votre part à ce sujet, car le clustering n'est pas un sujet simple et coûte cher à mettre en œuvre dans le monde des SGBDR.Il y a beaucoup de discussions/bravades sur le clustering dans le monde non relationnel de Google Bigtable, etc.mais ils résolvent un ensemble de problèmes différent et perdent certaines des fonctionnalités utiles d'un SGBDR.

Answer 10

Il y a plusieurs significations de « base de données »

• la boîte à matériel
• le logiciel en cours d'exécution (par ex."l'oracle")
• l'ensemble particulier de fichiers de données
• la connexion ou le schéma particulier

Il est probable que Joel parle de l'une des couches inférieures.Dans ce cas, il s'agit simplement de gestion de la configuration logicielle...vous n'avez pas besoin de patcher 1 000 serveurs logiciels pour corriger un bug de sécurité, par exemple.

Je pense que c'est une bonne idée, afin qu'un bug logiciel ne divulgue pas d'informations entre les clients.Imaginez le cas d'une clause Where errante qui me montrait vos données client ainsi que les miennes.