Quali sono le migliori pratiche per la scrittura di report? [chiuso]

A differenza dei voti da chiudere, penso che questa sia una domanda eccellente e disponibile.

L'unica cosa più importante nella segnalazione è capire i tuoi dati e il tuo modello di dati. Intendo davvero capirlo, devi essere in grado di guardare i risultati che ottieni mentre stai sviluppando ed essere in grado di dire se sono i risultati giusti. Hai bisogno di sapere quando hai bisogno di avere un join di sinistra un inner join per esempio (sai se ogni tabella nella tua query ha o dovrebbe avere un record corrispondente in ogni altro tavolo a cui è unito?) Hai bisogno di sapere dove per trovare le informazioni e come aggregarle correttamente e quali condizioni potrebbero essere necessarie che non sono ovvie.

Le query di report sono spesso estremamente complesse e restituiscono o consolidano i risultati di molti record, di conseguenza l'SQL che scrivi per loro deve essere molto più performante di quanto la maggior parte delle persone sia abituata a scrivere. Questo è particolarmente vero in un rapporto che presenterà tutti i dati in un periodo di tempo. Questo rapporto crescerà, crescerà e crescerà in numero di record restituiti e diventerà più lento e lento da eseguire. Tecniche come subquery correlate che sembrano valide quando si hanno solo dati di un mese o dati di test falliscono miseramente quando si utilizzano dati per 3 anni (utilizzare invece CTE o tabelle derivate). Non li usano Chi scrive i report deve leggere il capitolo sulle query in un libro di ottimizzazione delle prestazioni per il database back-end che si sta utilizzando. Ci sono molte tecniche da evitare.

Per quanto riguarda la progettazione del report, in genere ti viene detto quali elementi del filtro e quali colonne nei requisiti. Non ci sono scuse per l'invio di un rapporto ai test che non altera i requisiti. Purtroppo le persone fanno tutto il tempo.

Una tecnica che utilizzo nello sviluppo della query consiste nell'avviare la selezione finale (o la selezione originale se non ho alcune elaborazioni complesse di pre-elaborazione) con l'elenco dei requisiti. Quindi prima scrivo

SELECT 
 [COLUMN 1 NAME]  
 ,[COLUMN 2 NAME] 
 ,[COLUMN 3 NAME] 
FROM

Quindi commento tutte le colonne.

Quindi inizio a scrivere i join e le condizioni e ad aggiungere nomi e calcoli di campi effettivi e decommentarli uno alla volta e controllare i dati. Quindi, dopo che il primo campo funziona, potrebbe apparire come segue:

SELECT 
  t1.field1 as[COLUMN 1 NAME]  
 --,[COLUMN 2 NAME] 
 --,[COLUMN 3 NAME] 
FROM table1 t1
WHERE t1.field3 = 'Yes'

Quindi potrebbe apparire come segue:

SELECT 
  t1.field1 as [COLUMN 1 NAME]  
 ,coalesce(t2.field4, t1.field6) as [COLUMN 2 NAME] 
 --,[COLUMN 3 NAME] 
FROM table1 t1
JOIN table2 t2 on t1.table1id = t2.table1id
WHERE t1.field3 = 'Yes'

E così via. Se si esegue un blocco alla volta e la selezione finale inizia con tutte le colonne e i relativi nomi esatti in base al requisito, sarà più facile sia creare la query del report sia eseguirne il debug. IN SQL server abbiamo anche la possibilità di utilizzare CTE. Li uso estesamente nei report in modo da poter afferrare blocchi di dati e controllare che ogni blocco abbia ciò che voglio prima di mettere tutto insieme. Le tabelle derivate sono anche fondamentali per la segnalazione se non si dispone di CTE disponibili.

Se ricevo dati errati, potrei aver bisogno di vedere l'intero record di ogni tabella per capire che cosa sta causando un ritorno errato. Quindi tendo anche ad aggiungere un commento selezionato * che posso usare per vedere tutto se ne ho bisogno. Un po 'come:

SELECT 
  t1.field1 as [COLUMN 1 NAME]  
 ,coalesce(t2.field4, t1.field6) as [COLUMN 2 NAME] 
 --,[COLUMN 3 NAME] 
--SELECT *
FROM table1 t1
JOIN table2 t2 on t1.table1id = t2.table1id
WHERE t1.field3 = 'Yes'

Per eseguire la query completa, avviare l'evidenziazione dalla seconda selezione attiva. Fallo solo su dev!