strumenti di facile utilizzo per il recupero dei dati da un database di SQL Server

Question

Abbiamo diversi database di SQL Server contenenti misure da generatori che costruiamo. Tuttavia, questi dati utili sono accessibili solo a un paio di ingegneri poiché la maggior parte non hanno familiarità con SQL (me compreso). Ci sono strumenti permetterebbero un ingegnere per estrarre sottoinsiemi scelti dei dati al fine di analizzare in Excel o in un altro ambiente? Lo strumento ideale sarebbe

1. proteggere il database da eventuali modifiche accidentali,
2. richiedere alcuna conoscenza di SQL per estrarre i dati,
3. essere molto facile da utilizzare, ad esempio con una GUI per selezionare i campi e l'intervallo di tempo scelto,
4. consentire l'esportazione dei valori dei dati in un file che può essere letto da Excel,
5. non richiedono la partecipazione / ingresso dal gestore di database per l'attività di estrazione di correre, e
6. essere facile per un gestore di database novizio di set up.

Grazie per eventuali raccomandazioni o suggerimenti.

Answer 1

Prima di tutto, non avrei mai consentire agli utenti di gestire le loro proprie query su una macchina di produzione. Potrebbero eseguire scansioni di tabella o qualche altro killer di prestazioni per tutto il giorno.

Abbiamo una situazione simile, e creiamo generalmente stored procedure personalizzate per gli utenti di "chiamata", e consentire solo l'accesso a un server di backup che esegue i dati "quasi in tempo reale".

I nostri utenti hanno familiarità con Excel, in modo da creare una stored procedure con ampi parametri per il filtraggio / personalizzazioni e possono facilmente chiamare usando qualcosa come:

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

I documentare esattamente quali sono i parametri fanno, e in genere sono buone per andare da lì.

Per impostare una query di Excel è necessario impostare le fonti di dati sul PC dell'utente (pannello di controllo - dati FONTI ODBC)., Che varierà leggermente a seconda della versione di Windows

Da in Excel, è necessario impostare il "query", che è solo il comando EXEC dall'alto. A seconda della versione di Excel, dovrebbe essere qualcosa di simile: Menu - Dati - Importa dati esterni - nuova query di database. Quindi selezionare la sorgente di dati, collegare, saltare il diagramma creatore tavolo e immettere lo SQL sopra. Inoltre, non provare a fare una procedura di fare tutto, fare quelle diverse in base a quello che fanno.

Una volta che i dati sono sul foglio excel, i nostri utenti tirano ad altri fogli e manipolare a piacimento.

Alcuni utenti sono un po 'avanzata e "prova" per scrivere il proprio SQL, ma che è un dolore. Finisco per il debug e fissare le loro domande non corrette. Inoltre, una volta che fate la query corretta, hanno sempre armeggiare con esso e rompere di nuovo. utilizzando una stored procedure mezzi che non possono cambiare, e posso metterlo con le nostre altre procedure nel repository del codice sorgente.

Answer 2

I consiglierei di costruire il proprio in Excel. Excel può rendere le query al database di SQL Server tramite una connessione ODBC. Se lo fate a destra, l'utente finale deve fare poco più di fare clic su un pulsante di "ottenere i dati". Poi hanno accesso a tutta la potenza grafica di Excel per visualizzare i dati.

Answer 3

Excel consente di caricare l'output di stored procedure direttamente in una scheda. Questo è il modo migliore IMO:. Gli utenti hanno bisogno di alcuna conoscenza di SQL, hanno appena invoke una procedura, e non ci sono parti in movimento in più oltre a Excel e database

Answer 4

A seconda della versione di SQL Server che sarebbe guardando alcune delle eccellenti self service strumenti di BI con le edizioni successive, quali report. Questo è come una versione ridotta di Visual Studio con tutti i bit complessi sottoscritti e solo il semplice bit di segnalazione lasciati in.

Se si imposta un'origine dati condivisa che viene registrato in un server con diritti di accesso piuttosto bassi quindi gli utenti possono creare report ma non modificare nulla.

Mi associo ai commenti da KM che lasciando le grandi query esecuzione non lavate su un sistema di produzione può portare ad alcuni risultati interessanti sia con la query di sbagliato in uso o scansioni di tabella massicce o cartesiano si unisce etc