¿Cuáles son sus mejores prácticas para garantizar la exactitud de los informes de SQL?

Question

Parte de mi trabajo consiste en crear informes y datos de SQL Server para utilizarlos como información para la toma de decisiones. La mayoría de los datos se agrega, como los totales de inventario, ventas y costos de los departamentos y otras dimensiones.

Cuando estoy creando los informes, y más específicamente, estoy desarrollando los SELECT para extraer los datos agregados de la base de datos OLTP, me preocupa confundir un JOIN o GROUP BY, por ejemplo, devolver resultados incorrectos.

intento utilizar algunas "buenas prácticas" para impedir que me para "generar" números equivocados:

• Al crear un conjunto de datos agregados, siempre explotar este conjunto de datos sin la agregación y buscar cualquier error evidente .
• Exportar el conjunto de datos descompuesto a Excel y comparar SUM(), AVG(), etc., desde SQL Server y Excel.
• Involucre a las personas que usarían la información y solicite alguna validación (solicite a las personas que ayuden a identificar errores en los números).
• Nunca despliegues esas cosas por la tarde; cuando sea posible, trata de echar un vistazo al T-SQL a la mañana siguiente con una mente renovada. He corregido muchos errores usando este sencillo procedimiento.

Incluso con esos procedimientos, siempre me preocupan los números.

¿Cuáles son sus mejores prácticas para garantizar la exactitud de los informes?

Answer 1

ha considerado llenar sus tablas con datos de prueba que producen resultados conocidos y comparar los resultados de su consulta con los resultados esperados.

Answer 2

• firmado, por escrito

He descubierto que una de las mejores prácticas es que tanto el lector/cliente y los desarrolladores están en la misma página (documentado). De esa manera, cuando aparecen los números misteriosos (y lo hacen), que puede apuntar a la especificación por escrito y decir: "Esto es por eso que ver este número. ¿Le gustaría que fuera diferente?".

• Prueba, prueba, prueba

Para informes seriamente complicadas, que fue a través de los datos de prueba de arriba abajo con el cliente, hasta que todos los números eran correctos, y el cliente se estaban satisfechos.

• casos extremos

Descubrimos un caso serio complicada en nuestro sistema de información que resultó todo al revés (por nuestra parte). ¿Qué pasa si el usuario genera un informe (por ejemplo el cierre de 2009), introduce los datos para el nuevo año, y luego vuelve a generar el mismo informe? Los datos han cambiado pero ese informe no debería. Pensar y trabajar en estos casos puede ahorrarle muchos dolores de cabeza.

Answer 3

escribir algunas pruebas automatizadas.

Tenemos un buen montón de informes de informes de los servicios - los probamos el uso de selenio.Utilizamos una página de datos de prueba para enviar algunos datos conocidos a una base de datos vacía, luego ejecutamos el informe y afirmamos que los números son los esperados.

Las construcciones se ejecutan cada vez que nos registramos, por lo que sabemos que no hemos hecho nada demasiado estúpido