herramientas fáciles de usar para recuperar datos de una base de datos de SQL Server

Question

Tenemos varias bases de datos de SQL Server que contienen mediciones de los generadores que construimos. Sin embargo, este dato útil es sólo accesible a unos pocos ingenieros ya que la mayoría no están familiarizados con SQL (incluido yo). ¿Hay herramientas permitirían a un ingeniero para extraer subconjuntos seleccionados de los datos con el fin de analizarlo en Excel o en otro ambiente? La herramienta ideal sería

1. proteger la base de datos de todos los cambios accidentales,
2. requerir ningún conocimiento de SQL para extraer datos,
3. sea muy fácil de usar, por ejemplo, con una interfaz gráfica de usuario para seleccionar los campos y el intervalo de tiempo elegido,
4. permitir la exportación de los valores de los datos en un archivo que pueda ser leído por Excel,
5. no requieren la participación / entrada del gestor de bases para la tarea de extracción para funcionar, y
6. sea fácil para un gestor de bases de novato de configurar.

Gracias por las recomendaciones o sugerencias.

Answer 1

En primer lugar, nunca dejaría que los usuarios ejecutan sus propias consultas en una máquina de producción. Podrían ejecutar escaneos de tablas o algún otro asesino en el rendimiento durante todo el día.

Tenemos una situación similar, y en general, crear procedimientos almacenados personalizados para los usuarios "llamada", y sólo permiten el acceso a un servidor de copia de seguridad de datos funcionando "casi en vivo".

Nuestros usuarios están familiarizados con Excel, por lo que se crea un procedimiento almacenado con amplios parámetros para filtrar / personalizaciones y ellos pueden llamar fácilmente mediante el uso de algo como:

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

Me documentar exactamente lo que hacen los parámetros, y por lo general son buenos para ir desde allí.

Para configurar una consulta de Excel que necesita para configurar las fuentes de datos en el PC del usuario (panel de control - los datos de fuentes-ODBC)., Que variará ligeramente dependiendo de su versión de Windows

A partir de Excel, es necesario configurar la "consulta", que es simplemente el comando EXEC desde arriba. Dependiendo de la versión de Excel, debe ser algo así como: Menú - datos - importación de datos externa - nueva consulta de base de datos. Entonces optó por la fuente de datos, conexión, omita el fabricante diagrama de la tabla y escriba el SQL anterior. Además, no se trata de hacer un procedimiento de hacer todo lo posible, hacer que las diferentes sobre la base de lo que hacen.

Una vez que los datos están en la hoja de Excel, los usuarios tire de ella a otras hojas y manipulan a su antojo.

Algunos usuarios son un poco avanzado y "tratar" a escribir su propio SQL, pero eso es un dolor. Termino la depuración y la fijación de sus consultas incorrectas. Además, una vez que usted hace la consulta correcta, siempre jugar con él y se rompen de nuevo. utilizando un medio de procedimientos almacenados que no pueden cambiar, y puedo decirlo con nuestros otros procedimientos en el repositorio de código fuente.

Answer 2

Yo recomendaría a construir su propia en Excel. Excel puede hacer las consultas a su base de datos SQL Server a través de una conexión ODBC. Si lo haces bien, el usuario final tiene que hacer poco más que hacer clic en un botón de "obtener datos". Después, tienen acceso a toda la potencia de interfaz gráfica de usuario de Excel para ver los datos.

Answer 3

Excel permite cargar la salida de procedimientos almacenados directamente en una ficha. Que la OMI es la mejor manera:. Usuarios no necesitan conocimientos de SQL, que acaba de invocar un procedimiento, y no se mueven no extra partes, además de Excel y su base de datos

Answer 4

Dependiendo de la versión del servidor SQL que estaría buscando en algunas de las excelentes herramientas de BI de autoservicio con las ediciones posteriores, como el Generador de informes. Esto es como una versión simplificada de Visual Studio con todos los complejos trozos sacados y sólo los bits de información que quedan en simples.

Si configurar un origen de datos compartido que inicia sesión en el servidor con derechos de acceso muy bajas entonces los usuarios pueden crear informes, pero no editar nada.

Me hago eco de los comentarios de KM que dejar que las grandes consultas de ejecución sin lavar en un sistema de producción puede dar lugar a algunos resultados interesantes, ya sea con la consulta mal utilizado o escaneos de tablas masivas o cartesiano se une etc.