Je travaillais sur un nouveau projet qui a besoin d'utiliser 7 bases de données, arguant que les performances, la stabilité, l'optimisation sont plus facilement implémentées.
Bien que je ne sois pas d'accord, j'ai du mal à collecter de bons arguments pour utiliser une seule base de données (diviser les tables en domaines logiques).
Un argument que j'ai jusqu'à présent est l'intégrité des données (je ne peux pas utiliser de clés étrangères entre les bases de données).
Quels sont les avantages / inconvénients de l'utilisation d'une ou de plusieurs bases de données?
[résumé jusqu'à présent]
Arguments contre plusieurs bases de données:
Perte de l'intégrité des données (impossible d'utiliser des clés étrangères sur des bases de données)
Perte de l'intégrité de la restauration
Gagner en complexité (utilisateurs / rôles db)
Le serveur / la base de données à petite cote va baisser
Solutions:
Utilisez des schémas pour séparer les domaines.
POC: Utilisez des données factices pour prouver le point dans les plans d'exécution de 7/1 db
Réponses:
Aucune performance, stabilité, optimisation n'est vraie. Quelqu'un a-t-il un argument solide ou un article de référence expliquant pourquoi cela serait vrai?
Les ressources ne sont pas allouées à une base de données: l'instance SQL Server équilibre les ressources, donc cela ne fait aucune différence
Tu as perdu:
Vous gagnez en complexité:
Options:
la source
De bonnes raisons de créer des bases de données distinctes seraient de prendre en charge différentes exigences de disponibilité ou de simplifier l'administration. Par exemple, si vos bases de données nécessitent des planifications de sauvegarde très différentes ou des modèles de récupération différents. Une autre raison serait que vous souhaitiez les exécuter sur différentes instances.
Il n'y a aucune optimisation des performances disponible avec plusieurs bases de données que vous ne pouvez pas également réaliser avec une seule base de données. Pouvez-vous donner plus de détails sur ce que vous entendez par "performances, stabilité, optimisation"?
la source
Si vous êtes après avoir fractionné les données par domaine logique, vous pouvez toujours envisager d'utiliser des schémas dans SQL2008 (en vous éloignant de la valeur par défaut de dbo). schéma standard.
J'ai été en mesure de rassembler des données de plus d'une base de données et c'est douloureux et loin d'être performant. Vous finissez par mettre en cache des données ou au moins à utiliser des astuces pour maintenir la vitesse.
À titre de test, créez 7 bases de données factices. Créez une requête qui nécessite simultanément des données des 7 ou au moins un bon nombre d'entre elles.
Comparez ensuite les plans d'exécution! Je pense que vous gagnerez votre cause ici.
la source
Expérience de réflexion: au lieu de diviser votre base de données en sept morceaux, divisez-la plutôt en 7 000 morceaux. Quelle est la probabilité qu'une défaillance matérielle ait un impact sur votre application? S'il y a 0,1% de chance qu'un serveur particulier meure un jour donné, vos chances sont-elles meilleures ou pires que vous soyez affecté par une défaillance matérielle lorsque vous augmentez le nombre de machines dont vous dépendez?
Je pense qu'il est important de diviser la notion de "base de données" en deux parties: le schéma et les données par rapport au matériel utilisé pour servir les données.
Briser la base de données sur plusieurs machines ne vous sert à rien pour les nombreuses raisons expliquées par les autres réponses de cette rubrique.
Si vous comptez utiliser plusieurs machines pour des raisons de fiabilité et de performances améliorées, vous pouvez peut-être les structurer de manière à disposer d'un serveur maître avec plusieurs machines de secours chaudes / chaudes qui pourraient également être utilisées pour distribuer des requêtes. De cette façon, si une machine rencontre une défaillance, vous ne perdez aucune donnée et, au pire, vous devrez redémarrer une requête. Bien sûr, c'est plus complexe que cela, mais les bases s'appliquent.
la source
Je suis d'accord avec une base de données et j'utilise plutôt les options de fichier et de schéma.
Il y a des cas de bord où la division en plusieurs morceaux est logique.
Configuration de l'environnement d'application (dev, test, prod), comme les serveurs FTP, les chemins de fichiers d'exportation, etc ..., les trucs que vous souhaitez stocker par serveur et ne pas être écrasés lors d'une restauration.
Également comme moyen d'isoler les modifications de procédure spécifiques au client.
Mais ce sont des problèmes de support et non de performances.
la source