Des outils conviviaux pour la récupération de données à partir d'une base de données SQL Server

Question

Nous avons plusieurs bases de données SQL Server contenant des mesures à partir de générateurs que nous construisons. Cependant, ces données utiles est accessible à quelques ingénieurs, car la plupart ne sont pas familiers avec SQL (moi y compris). Y a-t-il des outils permettant un ingénieur d'extraire des sous-ensembles choisis des données afin d'analyser dans Excel ou un autre environnement? L'outil idéal serait

1. protéger la base de données de toute modification accidentelle,
2. ne nécessitent aucune connaissance de SQL pour extraire des données,
3. être très facile à utiliser, par exemple avec une interface graphique pour sélectionner les champs et la plage horaire choisie,
4. permettre l'exportation des valeurs de données dans un fichier qui peut être lu par Excel,
5. ne nécessitent aucune participation / entrée du gestionnaire de base de données pour la tâche d'extraction à exécuter et
6. être facile pour un gestionnaire de base de données de débutant à mettre en place.

Merci pour toutes les recommandations ou suggestions.

Answer 1

Tout d'abord, je ne serais jamais laisser aux utilisateurs d'exécuter leurs propres requêtes sur une machine de production. Ils peuvent exécuter des analyses de table ou d'un autre tueur de performance toute la journée.

Nous avons une situation similaire, et nous créons des procédures stockées personnalisées généralement pour les utilisateurs à « appel », et n'autorisons l'accès à un serveur de sauvegarde des données en cours d'exécution « presque en direct ».

Nos utilisateurs sont familiers avec Excel, donc je crée une procédure stockée avec des paramètres amples pour filtrer / personnalisations et ils peuvent facilement appeler en utilisant quelque chose comme:

EXEC YourProcedureName '01/01/2010','12/31/2010','Y',null,1234

Je exactement documenter ce que les paramètres font, et ils sont en général bon pour aller de là.

Pour configurer une requête Excel vous devez configurer les sources de données sur le PC de l'utilisateur (panneau de contrôle - la odbc de données)., Qui varie légèrement en fonction de votre version de Windows

De Excel, vous devez configurer la « requête », qui est juste la commande EXEC d'en haut. Selon la version d'Excel, il devrait être quelque chose comme: Menu - données - données externes import - nouvelle requête de base de données. Ensuite, choisissez la source de données, de connexion, passez le schéma fabricant de tables et entrez le SQL ci-dessus. En outre, ne pas essayer de faire une procédure tout faire, faire les différentes en fonction de ce qu'ils font.

Une fois les données sur la feuille Excel, nos utilisateurs tirent à d'autres feuilles et de manipuler à volonté.

Certains utilisateurs sont un peu avancé et « essayer » d'écrire leur propre SQL, mais qui est une douleur. Je finis par le débogage et la fixation de leurs requêtes incorrectes. En outre, une fois que vous faites correctement la requête, ils ont toujours bricoler avec elle et de le briser à nouveau. en utilisant un moyen de procédure stockée qu'ils ne peuvent pas changer, et je peux le mettre avec nos autres procédures dans le référentiel de code source.

Answer 2

Je vous recommande de construire votre propre dans Excel. Excel peut effectuer des requêtes à votre base de données SQL Server via une connexion ODBC. Si vous le faites correctement, l'utilisateur final doit faire un peu plus de cliquer sur un bouton « obtenir des données ». Ensuite, ils ont accès à toute la puissance de l'interface d'Excel pour afficher les données.

Answer 3

Excel permet de charger la sortie de procédures stockées directement dans un onglet. C'est la meilleure façon de l'OMI. Les utilisateurs ont besoin d'aucune connaissance de SQL, ils ont juste appeler une procédure, et il n'y a pas de plus en plus pièces en mouvement Excel et votre base de données

Answer 4

En fonction de votre version de serveur SQL je serais à la recherche quelques-uns des excellents services d'auto outils de BI avec les éditions ultérieures telles que le Générateur de rapports. Cela ressemble à une version dépouillée du studio visuel avec tous les bits complexes prises et juste les bits de simples rapports laissés dans.

Si vous configurez une source de données partagée qui se connecte sur le serveur avec des droits d'accès très faible, les utilisateurs peuvent créer des rapports, mais rien d'édition.

Je voudrais faire écho aux commentaires de KM que laisser les grandes requêtes d'exécution non lavés sur un système de production peut conduire à des résultats intéressants avec soit la mauvaise requête utilisée ou scans de tables massives ou cartésienne joint etc