Solutions de reporting

Question

Je sollicite des suggestions sur les solutions de reporting

Nous développons beaucoup de projets internes (serveur .net et sql). Pour les bases de données plus volumineuses, nous utilisons des objets métier et construisons des univers pour générer des rapports afin que les analystes ou les rédacteurs de rapports puissent créer des rapports et que les développeurs n'aient pas besoin d'être impliqués.

Beaucoup de nos projets contiennent des données importantes, mais ne sont pas assez grands pour construire des univers et des entrepôts de données. Nous devons encore générer des rapports à partir de ces données, mais nous ne voulons pas signaler les bases de données en direct car cela pourrait affecter les performances des applications. Pour certains de nos projets, nous effectuons des sauvegardes/restaurations nocturnes, dupliquant efficacement la base de données, puis utilisons la copie comme base de données de rapports. N'ayant pas beaucoup d'expérience en matière de reportage, je me demande quelles autres solutions les gens ont mises en place.

Answer 1

Dans des situations comme celles-ci, nous avons configuré transactional replication à partir de la base de données OLTP vers une base de données secondaire utilisée à des fins de génération de rapports.

Answer 2

Si vous exécutez 2008, vous pouvez utiliser le gouverneur de ressources pour limiter l'utilisation du processeur et de la mémoire sur votre serveur de base de données de production par vos utilisateurs. Le meilleur scénario est d'avoir un serveur de rapports dédié et DB, mais cela peut fonctionner.

Answer 3

L'approche la plus simple consiste à configurer un serveur pour rapporter et répliquer vos bases de données sur celui-ci. Exécutez les rapports sur le serveur de rapports.

Cela peut ne pas être très efficace pour les rapports, et aura probablement des problèmes de performances si vous avez une charge de travail importante. En fonction de vos exigences en matière de rapports, vous souhaiterez peut-être ajouter quelque chose entre un entrepôt de données et une suite de rapports à une copie de votre base de données opérationnelle. Des structures de reporting aplaties, plus simples et spécifiques au système, peuvent souvent être mises en œuvre assez rapidement. Construisez un processus ETL de base pour le remplir avec un rafraîchissement nocturne, et vous aurez quelque chose qui peut être rapporté raisonnablement efficacement.

Pour des besoins analytiques plus complexes ou si vous souhaitez utiliser des cubes, vous devrez peut-être vous attaquer au tir et construire un entrepôt ou un entrepôt de données approprié. Dans l'un ou l'autre de ces derniers scénarios, SQL Server est fourni avec un outil appelé Générateur de rapports (à partir de SQL Server 2005), qui peut être considéré comme un objet métier pauvre. Cela pourrait être utilisé pour fournir une capacité de rapport ad hoc par rapport à une base de données de rapports. Cependant, comme vous n'avez aucun contrôle sur le code SQL produit par l'outil, il risque de ne pas fonctionner correctement si vous tentez de l'utiliser avec la structure de données brute de vos bases de données opérationnelles. Obtenir de bons résultats à partir d'un outil de ce type a tendance à exiger une base de données structurée pour bien fonctionner avec l'outil et le traitement ETL qui nettoie les données de façon à ce qu'elles se comportent assez bien.