SQL Server - base de données distincte pour les rapports?

Sur notre serveur SQL, nous avons une base de données pour chacune de nos applications Web. Pour les rapports, nous utilisons Reporting Services et toutes les données de rapport (y compris les paramètres de rapport) proviennent de procédures stockées.

Les procédures stockées se trouvent dans la même base de données que les données du rapport. Ainsi, par exemple, les procs qui servent les rapports Stock sont dans la base de données Stock. Certains rapports affichent des informations provenant de plusieurs bases de données, puis le processus se trouvera dans l'une de ces bases de données source. Les paramètres du rapport obtiennent leurs données de procs dans une base de données d'entreprise qui contient des données comme les magasins, les employés, etc.

Cela signifie que tous les rapports ont au moins une connexion à la base de données Enterprise et une autre connexion à une autre base de données - et parfois plus que cela.

Ma question est la suivante: y a-t-il un avantage à déplacer les processus de génération de rapports dans une base de données "Rapports" distincte . Je connais les avantages de déplacer des rapports sur un autre serveur et je ne parle pas de cela - ce serait sur le même serveur.

Les choses qui pourraient affecter cela sont:

• Le fait d'avoir plus d'une connexion à la base de données pour un rapport affecte-t-il la vitesse du rapport?
• Le fait d'avoir le processus de génération de rapports dans une base de données distincte des données nous empêcherait-il d'utiliser des vues indexées?
• Avez-vous trouvé plus facile / plus difficile de gérer vos rapports dans une base de données distincte?

S'il vous plait, faite moi part de votre avis.

La réponse est: oui, il y a un avantage à le faire. Les rapports sur la base de données opérationnelle utiliseront beaucoup de ressources et interféreront avec les performances du système opérationnel. Rappelez-vous que les performances de la base de données sont soumises à des contraintes mécaniques (têtes de disque se déplaçant d'avant en arrière et latence de rotation pendant que nous attendons que le bon secteur apparaisse sous la tête). Vous avez deux grandes options pour une stratégie de reporting:

1. Répliquez votre base de données sur un autre serveur et déplacez-y les sprocs de génération de rapports. Les rapports sont exécutés sur le serveur répliqué. Ceci représente le moindre effort et peut réutiliser vos rapports et procédures stockées existants.
2. Créez un entrepôt de données qui consolide les données de vos systèmes de production et les transforme en un formulaire beaucoup plus convivial pour les rapports . Si vous avez beaucoup de rapports statistiques ad hoc qui pourraient être effectués de manière acceptable à partir d'un instantané à la «fermeture des bureaux hier», un entrepôt de données pourrait être la meilleure approche.

Je pense que cela dépend beaucoup du type de SP que vous utilisez. S'ils sont lourds et pourraient affecter d'autres choses en cours d'exécution sur le serveur de base de données, je les déplacerais. Sinon, j'essaierais de garder le plus près de la base de données sur laquelle ils rendent compte, si cela est beaucoup plus facile à maintenir et à suivre. Le simple fait que le rapport soit proche de la base de données réelle peut également affecter les performances, mais si vous utilisez une configuration standard et ne déplacez pas une énorme quantité de données, ce serait une toute petite différence, je suppose.

J'ai également trouvé cet article utile.

Je déconseille de déplacer les procédures stockées vers une autre base de données pour plusieurs raisons. Du point de vue du développement, vous devez reproduire deux bases de données chaque fois que vous souhaitez apporter des modifications. Par conséquent, vous allez maintenant savoir comment synchroniser le schéma de la base de données "data" et les procédures stockées de la seconde avec les versions de production. En ce qui concerne la récupération après sinistre et la sauvegarde / restauration, vous devez maintenant vous préoccuper de la restauration de la base de données 2 juste pour que votre système soit opérationnel.

Lors des tests, vous avez également ajouté des complexités. Vous aurez plus de points d'échec en ce qui concerne les autorisations, les versions, etc. Maintenant, si plus d'une personne travaille sur différentes initiatives sur la ou les bases de données, vous avez plus de temps à coordonner les efforts. Imaginez maintenant qu'il est 3 heures du matin, le système est en panne et vous devez rechercher les autorisations sur toutes les bases de données et vous assurer que personne n'a laissé de fonction ou de procédure sur la mauvaise base de données pendant le développement.

Je vous recommande d'utiliser deux bases de données.

La dérivation de rapports à partir d'une base de données «en direct» entraîne des problèmes de performances.

De plus, comme la base de données de rapports est principalement destinée aux recherches, vous pouvez personnaliser les index ici pour de meilleures performances. (La base de données en direct aurait des insertions qui seraient affectées négativement par certains index)

Une autre approche consiste à déplacer les tableaux de rapports vers un schéma et un groupe de fichiers distincts. Les fichiers du groupe de fichiers de rapports peuvent être éloignés des disques durs de données. Cela semble beaucoup plus facile pour l'administration, le développement futur et la gestion des accès.