Separazione SQL segnalazione Strato e presentazione?

Question

sto usando SQL Server Reporting Services. La maggior parte delle mie domande gestiscono i rapporti che vengono semplicemente esportate in formato PDF.

Mi piacerebbe sapere quale tipo di calcoli, se del caso, dovrebbe fare nella query SQL attuale e che dovrebbe essere calcolato con la SSRS IDE (Business Intelligence Studio).

Per esempio, se ho un rapporto di 12 mesi le vendite (12 mesi), che richiede un venduto medio di 3 mesi più recenti, in cui che dovrebbe essere media calcolata?

dovrebbe maggior parte dei calcoli / aggregazioni essere fatti nello strato di presentazione? Eventuali deroghe?

Answer 1

Questo potrebbe essere visto in 2 modi:

• dove si fa a mettere la logica di business
• è necessaria dato tempo per i calcoli, dove è più efficiente

La risposta a uno di questi è "dipende". Per il vostro esempio di un rapporto di 12 mesi che le tendenze mostrate anche, se si dispone di un paio di parametri che cambiano la logica utilizzata per ottenere i dati, sarei tentato di fare il più possibile nella procedura SQL memorizzato (anche il medie) e rendono il rapporto abbastanza "stupido" per visualizzare solo i risultati. Se il rapporto è molto semplice o la logica è specifico per quel rapporto solo, poi nell'opera rapporto potenza.

Per riutilizzabilità I favore fare le cose in SQL. Per le cose complesse di visualizzazione (heatmapping, grafici, ecc), nel rapporto è probabilmente meglio.

Answer 2

Mantenere la logica del rapporto con la relazione. SQL Server vi darà i dati, ma è meglio tenere la logica personalizzata con la relazione.

Answer 3

Vorrei stare lontano da avere la segnalazione di make andata e ritorno al database per i calcoli. Se la stored procedure (s) raggruppamento e ordinamento partite layout del report allora SSRS è abbastanza efficiente a fare calcoli aggregati.