Planification de la base de données - Schémas multiples vs bases de données multiples vs grande base de données unique vs partitions

Je recommanderais probablement d'opter pour une base de données par client, mais si vous voulez vous en tenir à une seule base de données, il semble que les schémas conviendront à vos besoins.

Toutefois, en plus d'un schéma par client, je vous recommande de créer un groupe de fichiers par client, puis de placer tous les objets de la base de données pour chaque client dans ce groupe de fichiers. Cela présente plusieurs avantages :

1. Meilleure disponibilité de la base de données. Si un fichier de données appartenant à un client est corrompu, il est toujours possible de mettre en ligne le reste de la base de données. Le fichier de données corrompu peut alors être restauré à partir d'une sauvegarde, même si d'autres transactions sont en cours.
2. (Potentiellement) de meilleures performances. Au fur et à mesure que le système grandit, vous pouvez placer des groupes de fichiers sur différents périphériques de stockage et répartir vos E/S (bien sûr, vous pouvez faire quelque chose de similaire avec un groupe de fichiers et plusieurs fichiers, mais cela vous permettra de répartir les E/S par client).
3. Facilité des sauvegardes. Les sauvegardes de la base de données peuvent se faire au niveau du groupe de fichiers, ce qui vous donne plus de flexibilité quant au moment de sauvegarder les tables de chaque client.
4. Meilleure granularité de la restauration. Comme au point 1, lorsque vous restaurez la base de données à partir de zéro, une fois que le groupe de fichiers principal est en ligne, vous pouvez commencer à restaurer les groupes de fichiers individuellement, en commençant par votre client le plus important. Comme les restaurations ultérieures n'auront aucun impact sur les groupes de fichiers déjà restaurés, vous pouvez mettre votre base de données en ligne pièce par pièce plutôt qu'en une seule fois. C'est ce qu'on appelle une restauration en ligne au coup par coup et il s'agit d'une fonctionnalité réservée à l'édition entreprise (bien qu'il soit possible de faire quelque chose de similaire dans l'édition standard, mais cela nécessite que la base de données soit hors ligne).

Je crois que le nombre maximum de groupes de fichiers que vous pouvez avoir est d'environ 32 000, donc cette stratégie devrait durer jusqu'à ce que vous ayez vraiment besoin de penser à la séparation en différentes bases de données.

Pour plus d'informations, je recommande l'article de livres en ligne ' Architecture des fichiers et des groupes de fichiers et le livre blanc de SQLCAT sur la disponibilité partielle des bases de données : http://sqlcat.com/sqlcat/b/whitepapers/archive/2007/11/21/partial-database-availability.aspx

Si tous les clients partagent la même base de données et que tous les sites web utilisent le même modèle, il s'agit plutôt d'un système de gestion de contenu multi-locataires.

Je ne pense pas que le problème vienne des mises à jour d'un client qui affectent toutes les autres, mais plutôt d'un niveau inférieur de lenteur des mises à jour et des requêtes en général. En supposant que le matériel et la charge ne changent pas, 150 bases de données devraient fonctionner de la même manière que la solution à base de données unique (peut-être plus lentement dans certaines circonstances).

Je suppose que votre table principale est la table "listings" qui contient environ 150*1000 lignes vivantes (vraisemblablement + enregistrements historiques).

Il ne s'agit pas d'une quantité massive de données, loin s'en faut, et une machine raisonnablement équipée ne devrait pas rencontrer de problème.

Je m'assurerais que les enregistrements historiques sont déplacés vers leurs propres tables. Dans la requête de lecture, j'ajouterais "read uncommitted snapshot" (lecture d'instantanés non validés)

En ce qui concerne les mises à jour, il existe quelques solutions possibles pour résoudre ce problème 1. Utiliser une fusion plutôt que plusieurs déclarations de mise à jour 2. Utiliser un curseur pour éviter l'escamotage du verrou 3. Ajouter de nouveaux enregistrements pour les listes mises à jour, et simplement mettre à jour un indicateur de bit "est à jour" sur les anciens enregistrements.

Étant donné que cela s'est passé il y a deux ans, quelle a été la solution finale ?

Il semble que vous soyez plus préoccupé par le fait de tout conserver dans une seule base de données, quel qu'en soit le coût (bien que vous en ayez parlé), puisque le principal argument de Peter en faveur de la séparation en bases de données distinctes était lié aux performances et à la possibilité d'évoluer à long terme. Si c'est le cas, vous devriez soit diviser les tables en différents schémas pour les clients, soit passer à une licence Enterprise Edition pour pouvoir utiliser le partitionnement des tables et partitionner les tables partagées en fonction du nombre de clients.

Je me suis posé la même question lorsque j'ai envisagé de restructurer mon infrastructure de base de données. Cet article m'a beaucoup aidé.

[ [https://msdn.microsoft.com/en-us/library/aa479086.aspx\]\[1\]](https://msdn.microsoft.com/en-us/library/aa479086.aspx][1])