Quali sono gli svantaggi dell'utilizzo di stored procedure, SSIS e SSRS per implementare applicazioni aziendali? [chiuso]

Un problema con questa soluzione è che suppone che la soluzione sia basata su database, che il database sia un database relazionale e che sia accettabile inserire la logica nel database. Ci sono diverse sfide qui.

• Hai provato picchi usando tecnologie non relazionali come MongoDB? MongoDB è gratuito (sebbene offra supporto commerciale), incredibilmente facile da usare e molto meno complesso di un approccio basato su SQL. A seconda della struttura dei dati, potresti considerare un archivio di colonne (come Cassandra), un archivio di valori chiave (come Riak) o un database di grafici (come Neo4J). Se vuoi saperne di più su questi tipi di database prova a consultare il libro NoSQL Distilled link
• A volte è considerato vantaggioso centralizzare la logica aziendale nel minor numero di posti possibile. Può rendere la tua applicazione molto più facile da gestire quando il codice sorgente è espressivo e disposto in un modo che è facile da comprendere per i programmatori, ed è piuttosto difficile farlo in SQL. Inoltre è difficile mantenere il codice SQL - non c'è un supporto per il re-factoring decente, il supporto per l'analisi del codice, gli IDE decenti sono difficili da trovare.
• Anche se è sempre più facile fare integrazione continua, test driven development e continuous delivery con i moderni ambienti di programmazione software, non è molto più semplice automatizzare la porzione di database della tua app. Molti team hanno difficoltà a automatizzare le migrazioni, coordinando le versioni del database con versioni del software e altre difficoltà. Non aiuta molto spesso ad automatizzare la distribuzione della tua applicazione in diversi ambienti, avrai problemi di gestione delle licenze che renderanno più difficile l'integrazione continua e la consegna continua. Ciò è aggravato dal fatto che non esiste un ricco ecosistema di framework di test per SQL, il che renderà più difficile sviluppare una suite di test che ti dia la sicurezza di non aver infranto la tua app.

Sempre di più, molti team stanno considerando il database un'opzione per la persistenza; non per logica o funzionalità. Ciò sta portando a una migliore architettura e applicazioni che sono più facili da gestire, testare e implementare.

TLDR

• L'archiviazione delle query separate dai report che guidano creerà un problema nel database; se stai andando per semplici query SQL, inseriscile nel rapporto.
• Considerare l'utilizzo di SSAS (SQL Server Analysis Services) o SSRS Report Models (a volte chiamato anche modello semantico) anziché semplici query SQL vecchie. Non sempre possibile, ma generalmente funziona meglio.
• Non inserire elementi come il calcolo dei dati delle prestazioni in codice procedurale come Java o C #, è meglio renderli parte di una vista in cima al tuo database (come le funzionalità SSRS o SSAS sopra menzionate), hanno prestazioni migliori e si trovano logicamente nello stack dei rapporti.

Risposta completa

Il più grande svantaggio del backup dei report con le stored procedure è che il report e la query per riempirlo sono archiviati separatamente e mentre il report indica quale query dipende, le stored procedure non ti dicono quali risorse dipendono su di essi. Ora, si potrebbe iniziare con l'intenzione di avere una rigida mappatura 1-a-1 delle stored procedure ai report, ma nella mia esperienza, qualcuno proverà ad essere più furbo in seguito e a sovrapporre la stored procedure a un'altra, e tu finire con una rete di dipendenze (ho trascorso gli ultimi 6 mesi in un progetto per migliorare leggermente la situazione sul mio posto di lavoro). Se mantieni una documentazione rigorosa, puoi affrontarla, ma ammettiamolo, la documentazione è difficile e noiosa e quasi sempre superata.

Una soluzione migliore per l'utilizzo delle stored procedure consiste nell'incorporare la query direttamente nel report, in questo modo il report e la query sono accoppiati tra loro, risiedono insieme e non si ottengono altri asset dipendenti che si bloccano senza il proprio conoscenza. So che questo va di pari passo con la "saggezza convenzionale" sul riutilizzo del codice, ma SQL non è un codice, e le catene di dipendenza non possono essere determinate da nessuna parte così come facilmente è nel codice compilato.

Un altro svantaggio delle stored procedure è che non sono in realtà il modo migliore per generare rapporti, specialmente quando si parla di calcolare gli aggregati su un periodo di 25 anni. SSAS (Sql Server Analysis Services) è specificamente progettato per questo tipo di query e facilita un metodo molto più user-friendly di creazione di query e report (il potenziamento degli utenti nella creazione di report è brillante). Inoltre, consente di interrogare gli stessi dati tramite Excel come tabelle pivot ecc (che la gente ama). L'intera direzione di Microsoft con i report è di spostare l'interrogazione dal database e nel livello SSRS / SSAS. Non sarai sempre in grado di produrre tutti i tuoi report in questo modo e dovrai ricorrere a una query SQL scritta a mano a un certo punto, ma conservala nel report.

Ora, come per la domanda sul fatto che la "logica di business" dovrebbe essere in Java. Se stai parlando di calcoli per varie statistiche, o KPI, essenzialmente funzioni statiche sui dati, piuttosto che qualsiasi cosa che riguarda l'interazione dell'utente, allora no, non dovresti attaccare quelle cose nel codice. Dovrebbero far parte del tuo stack di rapporti. In Microsoft-land il posto migliore per metterli è in un modello SSRS o in un cubo di analisi (infatti i prodotti 2012 hanno una sostituzione per il cubo che offre lo stesso concetto senza la necessità di avere un passo di elaborazione batch, quindi funziona off live data).

Non sarei troppo preoccupato per il lock-in del fornitore. Passare a un altro database sarebbe un progetto molto grande per chiunque e sarebbe raro.

Argomenti per mettere tutta la logica di business nei proc memorizzati:

• Per l'elaborazione di dati molto pesanti, è necessario un codice ottimizzato molto bene. Questo è ciò che i database eccellono - ha molto senso scrivere SQL molto finemente sintonizzato e prestare molta attenzione agli indici e ai piani di query ecc. Questo diventerà senza dubbio in discussione se non si utilizza lo strumento / la tecnologia corretti per questo sollevamento pesante.

• I database (ad esempio, il server SQL) eseguiranno l'ottimizzazione delle prestazioni in base alla query utilizzando le statistiche. Questo è un grande vantaggio.

• Tutta la logica sarà in un posto e (se ben scritta) dovrebbe essere relativamente facile da mantenere, modificare e distribuire e script nel controllo del codice sorgente.

• Un sacco di persone sanno come scrivere e gestire procs, è una scienza molto matura.

Contro:

• I proc memorizzati possono trasformarsi in un disordine irraggiungibile se non scritti attentamente. Sebbene ciò sia vero per qualsiasi lingua, è particolarmente vero per i processi di archiviazione di SQL Server.

• L'esecuzione di qualsiasi logica che non funzioni direttamente dal database (ad esempio copia di file in giro) non è ciò per cui è progettato un database. Forse ha questa funzionalità, ma a mio parere si vuole sicuramente un'applicazione che faccia questo - quando si tratta di file FTP in giro, decomprimere ecc. Si vuole veramente il pieno controllo del codice dell'applicazione. Forse un database può fare questo genere di cose, ma nutro forti dubbi sul fatto che possa funzionare bene, fornire una buona gestione degli errori, ecc. E se fosse necessario decomprimere un file protetto da password? Cosa succede se il file è vuoto? Interruzione della connessione di rete? Il file è bloccato? Cosa succede se ... ecc. Sono sicuro che ci sono molti casi d'uso che il DB non può gestire.

• Il debug di grandi processi memorizzati può essere molto, molto difficile. Se le cose iniziano ad andare molto male allora ti trovi in un mondo di dolore.

• Può essere molto facile che i processi memorizzati non siano più sincronizzati tra i sistemi (Dev DB, UAT DB, DB di produzione). Questo deve essere fatto con molta attenzione. (Personalmente scrivo tutti i miei proc e come parte delle mie build / release eseguo i proc nei loro rispettivi database, ottimo una volta che è tutto pronto).

• (Ecco un'opinione per voi) - SSRS è un rompiscatole. Lo odio e così faccio la maggior parte degli sviluppatori che conosco, nessuno vuole lavorare quando li Cerca di assumere qualcuno per mantenere la roba su SSRS sarà molto più difficile che assumere uno sviluppatore Java.

Se fossi in me, scriverei un'applicazione Java per eseguire la gestione dei file e, se necessario, per l'elaborazione dei dati più impegnativa, userei i proc memorizzati. Il meglio dei due mondi e nessun SSRS :)

Il più grande vantaggio delle stored procedure è che sono limitate alle istruzioni T / SQL. Questo di solito riduce la complessità.

Una soluzione in un linguaggio più generale deve risolvere molti problemi che una procedura T / SQL non comporta: come mappare gli oggetti alle tabelle del database (ORM), come programmare le importazioni, come registrare le eccezioni, come connettersi al Banca dati. Ciò può diventare molto complesso, specialmente se l'autore cerca di risolvere il problema in modo generale.

Un vantaggio laterale è che T / SQL non cambia molto spesso. Una procedura memorizzata dal 1995 funziona bene su SQL Sever 2012. Al contrario, un linguaggio generico del 2008 sembra antiquato e datato oggi.

Non mi preoccuperei molto del blocco del fornitore. Cambiare i database è sempre una sfida complessa; Microsoft non si sbarazza di SQL Server in qualsiasi momento presto, quindi mi sentirò a mio agio nello specifico.

Non ho esperienza con SSIS e SSRS, ma utilizzo le stored procedure esclusivamente per l'accesso al database. Mi piacciono perché separano i dati dal consumo: come programmatore, non mi interessa sapere come conosco il valore di un portafoglio azionario, solo quello che è. Le stored procedure mi danno il potere di fare tutto ciò che funziona in un unico posto (e nel database, quindi non c'è mai la voglia di provare a far ruotare la propria logica basata sul set nel codice procedurale). Le prestazioni sono anche migliori, soprattutto quando si hanno serie di risultati e aggregazioni massicce.

Penso che dipenda da quanti rapporti stai correndo. Se solo alcuni hanno senso, basta usare le query incorporate perché sarà molto più veloce ed economico completare il lavoro. Se si costruiscono molti report rispetto alle stored procedure, in quanto riduce la necessità di scrivere codice SQL più e più volte e basta usare procs. Inoltre, se è probabile che la struttura del database cambi, è molto più facile cambiarla in un processo memorizzato e sfogliare tutti i tuoi rapporti alla ricerca di riferimenti.

Un'altra alternativa da notare è l'uso di set di dati condivisi. Questo potrebbe essere un compromesso tra le due scelte che stai cercando di confrontare e contrastare che potrebbero eventualmente risolvere il tuo problema. I set di dati condivisi sono riutilizzabili, rendendoli una scelta ottimale. L'unico problema con i set di dati condivisi è che sono realistici solo per i report senza parametri. Se si utilizza un report con parametri di ricerca, è preferibile utilizzare le stored procedure in quanto possono essere inoltrate.

Suggerirei un approccio ibrido basato sul bisogno. Inizia sempre con una query incorporata per eseguire il primo report di questo tipo. Se sono necessari altri report basati sulla stessa query utilizzando un set di dati condiviso o una stored procedure basata sui parametri necessari per il report.