Sql Server Reporting Services vs Reporting tramite applicazione .NET

Question

Il mio capo desidera che crei alcuni report nel prossimo futuro e penso che voglia utilizzare SQL Server Reporting Services per distribuire i report. Non sono così sicuro che questa sarebbe una grande idea, considerando che siamo un'organizzazione piuttosto piccola e non riesco a vederci sfruttando o richiedendo le funzionalità offerte da questa soluzione, come la configurazione di utenti, gruppi e abbonamenti.

Anche se non ho usato SSRS in precedenza, ho visto un webinar di 3 giorni su di esso e sembra che sia una di quelle cose che sono carine e OK per situazioni semplici ma diventa un dolore & troppo limitato quando i requisiti diventare più complesso. Preferirei di gran distribuire i rapporti i rapporti locali (.rdlc) in un'applicazione .NET perché:

1. Avrei preferito elaborare & formattare i dati con .NET poi SQL. Certo, è possibile utilizzare CLR, ma questa rotta sembra essere più difficile da mantenere e meno ideale rispetto all'elaborazione dei dati, come faccio normalmente in un'applicazione .NET.
2. Limitazioni sull'interfaccia utente quando si aggiungono i controlli dei parametri: se ricordo che non si ha molto controllo sul layout.

Quindi penso che la mia domanda sarebbe in quali situazioni funziona SSRS, quali situazioni non funziona bene? I miei punti sono validi o sono solo uno scettico?

Answer 1

È possibile impostare la sicurezza per i servizi di report come in Windows, quindi se un requisito di sicurezza cambia, è sufficiente modificare la sicurezza in RS. Se è incorporato in un'applicazione, è necessario aggiornare l'applicazione (non l'ho fatto, quindi non conosco tutti i passaggi) e quindi ridistribuire l'applicazione per aggiornare la sicurezza.

Answer 2

I tuoi punti sono validi.

Per un'app più piccola, prenderei in considerazione l'utilizzo di un controllo ReportViewer in un'app ASP.NET se non sono necessari tutti i campanelli e i fischi. Anche dal punto di vista della manutenzione: devi solo gestire una app. Il mio team ha intenzione di smettere di usare SSRS.

So che alcuni membri del nostro team affiliato hanno relazioni e strutture complesse e hanno bisogno di campane e fischietti.

Answer 3

Io uso un po 'di entrambi e ho scoperto che ci sono dei compromessi con ciascun approccio.

• Per qualsiasi motivo, il progettista di .rdlc è leggermente diverso dal designer per .rdl. Può diventare piuttosto confuso quando un esempio online fa ipotesi su ciò che è il tuo progettista.
• Generalmente preferisco i report distribuiti da SSRS se sto cercando di essere indipendente dal client, poiché i report basati su .rdlc richiedono di fornire il client.
• Generalmente preferisco i report basati su .rdlc per le applicazioni autonome, in particolare per i client che non dispongono di un centro dati. Questi tendono ad essere applicazioni in cui sia l'applicazione che il database si trovano sul computer client.
• Mi piace LINQ e trovo più semplice da utilizzare come origine dati per i report basati su .rdlc.
• Ho una relazione di amore/odio con i report basati su .rdlc quando si tratta di refactoring. Mantenere le strutture dei dati in una libreria separata rispetto ai rapporti è importante; in caso contrario, la modifica di un nome di proprietà causerà il fallimento della compilazione a causa del report, ma la nuova proprietà non sarà disponibile sull'origine dati per il report fino alla creazione.
• Controllo del client (.report basato su rdlc) offre flessibilità illimitata su come presentare e raccogliere i valori dei parametri, il che è molto carino.

In ogni caso, dubito che ci sia un approccio dogmatico si dovrebbe bastone, altro che "fare ciò che ha senso." Per me, in pratica, utilizzo i report basati su .rdlc per le applicazioni client di piccole dimensioni e distribuisco report di livello enterprise su un server SSRS.

Buona fortuna!

Answer 4

I tuoi istinti sono buoni, continua a usarli.

Molte persone cadono nella trappola di spingere la complessa logica di business in SQL e strumenti di reporting. Il posto giusto è nell'ETL. Non essere intimidito dal termine che copre semplici script perl ad-hoc a complessi SSIS. Anche allora l'80% delle volte le persone useranno SSIS solo per estrarre e caricare i dati salvando la trasformazione per il report in fase di esecuzione (perché questi report sono così lenti ?!).

Anche se si è costretti a fornire i dati tramite SSRS, mantenere il livello di trasformazione separato dal report nello strumento/lingua di propria scelta, mantenendo il proprio sql semplice e conciso.

Per un piccolo negozio, l'aspx è probabilmente soddisfacente, ma tenetelo a mente. Ottieni un sacco di roba gratis da SSRS con sicurezza ed esportazione per eccellere come un enorme vantaggio per il tuo capo. I rapporti sono anche un buco nero di lavoro occupato. La prima manciata di rapporti si moltiplica rapidamente per utenti diversi e per diversi motivi commerciali e diventa ingestibile. Se si imposta una buona base SSRS è possibile migrare il lavoro a qualcun altro quando è il momento giusto.

Se sei più interessato ti suggerisco di leggere il data warehousing.

Un'altra cosa. Sii consapevole dell'esecuzione di rapporti su dati in tempo reale. I report hanno in genere un profilo di prestazione diverso rispetto alle query OLTP. OLTP = pochi record al momento in cui le query di Reporting (DW) richiedono talvolta scansioni complete della tabella e possono causare problemi di blocco se non vengono configurate correttamente.

Answer 5

Nessuno ha detto nulla su Report Builder 2.0 o 3.0. È un'ottima app solo per creare report senza bisogno di SSRS o altro. Basta accenderlo e configurarlo per consumare qualsiasi fonte di dati che hai a disposizione e sei a posto. Voglio dire, puoi facilmente compilare questo rapporto in pochissimo tempo. Pensaci.

Non hai sicuramente bisogno di un'altra soluzione .NET su misura per questo.

Getting Started with Report Builder 3.0