Quali sono le migliori pratiche per garantire la correttezza dei report da SQL?

Question

Parte del mio lavoro riguarda la creazione di report e dati da SQL Server da utilizzare come informazioni per la decisione. La maggior parte dei dati viene aggregata, ad esempio inventario, vendite e costi totali dai reparti e altre dimensioni.

Quando creo i report e, più nello specifico, sto sviluppando i SELECT per estrarre i dati aggregati dal database OLTP, mi preoccupo di scambiare un JOIN o un GROUP BY, ad esempio, restituendo risultati errati.

provo ad usare alcune "buone pratiche" per impedirmi per "generare" numeri sbagliati:

• Durante la creazione di un set di dati aggregati, esplodere sempre questo insieme di dati senza l'aggregazione e cercare qualsiasi errore evidente .
• Esporta il set di dati esplosi in Excel e confronta SUM(), AVG(), ecc. Da SQL Server ed Excel.
• Coinvolgere le persone che desiderano utilizzare le informazioni e chiedere una conferma (chiedere alle persone di aiutare a identificare gli errori nei numeri).
• Non distribuire mai quelle cose nel pomeriggio - quando possibile, prova a dare un'occhiata al T-SQL la mattina successiva con una mente aggiornata. Ho avuto molti errori corretti usando questa semplice procedura.

Anche con quelle procedure, mi preoccupo sempre dei numeri.

Quali sono le migliori pratiche per garantire la correttezza dei rapporti?

Answer 1

hai considerato di riempire le tabelle con dati di test che producono risultati noti e confrontare i risultati della query con i risultati previsti.

Answer 2

• Firmato, per iscritto

Ho scoperto che una delle migliori pratiche è che sia il lettore/cliente e gli sviluppatori sono sulla stessa (documentato) pagina. In questo modo, quando compaiono numeri misteriosi (e lo fanno), posso indicare le specifiche per iscritto e dire "Questo è il motivo per cui vedi questo numero. Ti piacerebbe che fosse diverso?".

• Test, test, test

Per i rapporti sul serio complicate, siamo passati attraverso i dati di prova su e giù con il cliente, fino a quando tutti i numeri sono stati corretti, e il client è stato sono stati soddisfatti.

• casi limite

Abbiamo scoperto un caso seriamente complicato nel nostro sistema di reporting che ha trasformato tutto sottosopra (da parte nostra). Cosa succede se l'utente genera un rapporto (ad esempio, Fine anno 2009), inserisce i dati per il nuovo anno e quindi torna a generare lo stesso rapporto? I dati sono cambiati ma quella relazione non dovrebbe. Pensare e lavorare su questi casi può far risparmiare parecchio dolore.

Answer 3

Scrivere alcuni test automatici.

Abbiamo molti rapporti sui servizi di reportistica: li testiamo utilizzando Selenium.Utilizziamo una pagina di dati di prova per spruzzare alcuni dati noti in un database vuoto, quindi eseguire il report e affermare che i numeri sono come previsto.

Le build vengono eseguite ogni volta che effettuiamo il check-in, quindi sappiamo che non abbiamo fatto nulla di troppo stupido