In teoria, i pro e i contro sono così:

Pro:

1. Un posto per contenere tutta la logica aziendale
2. Possibili applicazioni più veloci perché più query SQL e simili possono essere eseguite in un "round trip" nel database
3. Trivial per utilizzare le stored procedure da più applicazioni

Contro:

1. Sarà richiesto un DBA per la regolazione delle prestazioni
2. Tutti gli sviluppatori dovranno essere molto esperti nel tuo particolare dialetto SQL (T-SQL, Pl / SQL, ecc.)
3. Il codice SQL non è così espressivo e quindi più difficile da scrivere quando si coprono concetti di livello superiore che non sono realmente correlati ai dati
4. Molto più carico non necessario sul database

Ora, praticamente, solo un pazzo avrebbe tutta la logica aziendale nel database.

1. Pochissimi sviluppatori saranno in grado di creare un'interfaccia di stored procedure coerente che funzioni facilmente attraverso le applicazioni. Di solito questo è dovuto al fatto che alcuni presupposti sono fatti di quell'applicazione chiamante
2. Lo stesso vale per la documentazione di tutte quelle stored procedure
3. I server di database hanno generalmente un collo di bottiglia sufficiente. Mettere il carico non necessario su di loro limita ulteriormente questo collo di bottiglia. Sarà necessario un bilanciamento del carico complesso e hardware robusto per qualsiasi cosa con una discreta quantità di traffico
4. SQL è appena un linguaggio di programmazione. Una volta ho avuto il piacere di mantenere un motore di scripting scritto come una stored procedure T-SQL. È stato lento, quasi impossibile da capire e ci sono voluti giorni per implementare quella che sarebbe stata un'estensione banale in molte lingue
5. Cosa succede quando un cliente ha bisogno del proprio database per eseguire un server SQL diverso? Devi fondamentalmente iniziare da zero: sei molto legato al tuo database. Lo stesso vale quando Microsoft decide di deprecare alcune funzioni che si usano un paio di volte attraverso le stored procedure
6. Il controllo del codice sorgente è estremamente difficile da eseguire correttamente con le stored procedure, soprattutto quando ne hai molte
7. I database sono difficili da mantenere sincronizzati. Che dire quando hai un conflitto di qualche tipo tra 2 sviluppatori che stanno lavorando nel database allo stesso tempo? Verranno sovrascritti gli uni dagli altri, il codice non ne è a conoscenza, a seconda della configurazione del "database di sviluppo"
8. Gli strumenti sono decisamente meno facili da utilizzare, indipendentemente dal motore di database che si utilizza.

Quindi, per rispondere obiettivamente alla domanda. Nella maggior parte dei casi, le procedure memorizzate sono necessarie solo in alcuni casi. Ad esempio, se si dispone di un report per generare dove è necessario eseguire un sacco di elaborazione condizionale su un paio di tabelle grandi, non si vorrebbe che la propria applicazione effettuasse un paio di centinaia di query SQL sul database. Si desidera eseguire una stored procedure in modo da non avere il sovraccarico della rete. Inoltre, in genere si desidera solo eseguire stored procedure per quando i client desiderano eseguire una query personalizzata sul database. Le procedure e le viste memorizzate possono rendere ciò facilmente possibile senza che i vostri clienti diventino un mago del database.

Contro:

• Il database è la parte scalabile minima della tua architettura,
• Soprattutto in un'epoca di servizi web e applicazioni web di terze parti REST-ful, non sarai in grado di contenere tutta la tua logica di business nei processi memorizzati.
• Le implementazioni SQL variano, alcune possono essere complicate e nessuna viene letta come un linguaggio di programmazione di livello applicazione di prima classe.
  • Ricorda che il codice è leggi molto più spesso di quanto sia scritto .

Vantaggi di mantenere tutta la logica aziendale sulle stored procedure nell'applicazione web per:

• Un posto è più facile da gestire rispetto a più
• I database sono veloci e ottimizzati e possono essere adattati bene.
• Le stesse procedure possono essere chiamate da mutiple, diversi framework e linguaggi.
• La logica è disaccoppiata dall'implementazione in particolari applicazioni.
• La rilavorazione può essere ridotta per cambiare le applicazioni quando il database rimane uguale.

Contro il mantenimento di tutta la logica aziendale sulle stored procedure nell'applicazione web: contro:

• Una buona conoscenza di SQL può essere difficile da trovare in molte località.
• I buoni codificatori SQL possono essere costosi.
• Tutti gli sviluppatori di applicazioni dovranno essere in grado di modificarlo o richiedere una modifica rapida.
• Alcuni dati meno adatti a un database SQL, ad es. dati di immagine o dati di un documento potrebbero non essere disponibili nel database e potrebbe essere difficile integrarlo con le stored procedure ..

Ci sono 2 grandi svantaggi che di solito incontrano:

1. Impossibilità di testare le tue procedure memorizzate. Certo, ci sono alcuni framework di test unitari, ma di solito si verificano problemi di esecuzione di più di un set di test contemporaneamente (problemi di concorrenza e di transazione).
2. La maggior parte delle aziende vorranno inserire molti login nei proc memorizzati, ma poi assumere 5x più programmatori di applicazioni (sia C #, Ruby, Java, qualunque) che programmatori di database o DBA, e per qualche ragione si aspettano che tutti i loro i codificatori di app dovrebbero comprendere appieno ed essere in grado di scrivere procedure database scalabili e performanti (in PL / SQL, T-SQL o qualsiasi altra cosa). Il management di solito non si rende conto che farlo è molto simile all'assunzione di un esperto di C # per scrivere un codice Python e chiedersi perché non scrivono applicazioni sorprendenti.

Dipende

Tutto dipende dalla tua team's experience e dalla tua project's requirements . Porta un DBA al tuo team e decidi cosa dovresti fare per soddisfare i requisiti. Tuttavia, con la progettazione di applicazioni multitier potrebbe non essere la buona decisione incapsulare la logica di business nella stored procedure.

Non ha importanza

Finché la logica aziendale:

• vive in un posto
• dove è adeguatamente documentato
• l'accesso corretto viene fornito attraverso servizi che possono essere liberamente accoppiati
• attraverso un'interfaccia astratta pubblicata

Penso che business logic in programming space makes more sense quando Power of Expression è importante nel tuo team / progetto.

Credo che lo spazio SQL non sia così espressivo, ma it can do the job . Utilizza i migliori strumenti che hai a disposizione per le attività più appropriate. È meglio fare i giocoli con la logica e i concetti di ordine superiore al highest level. Di conseguenza, la manipolazione dei dati di massa e di archiviazione è migliore a livello di server , probabilmente nelle stored procedure.

Nell'età moderna questo non è più un approccio comune. C'è stato un tempo in cui mettere la logica aziendale nelle stored procedure era una cosa comune da fare nelle prime fasi della programmazione web perché le alternative erano poche e spesso difficili da usare. Oggi consiglierei contro di esso.

Dovrei dire che nel 2012 non c'è nulla nella logica aziendale nelle stored procedure che potrebbe essere giustificato in quanto in qualche modo una scelta che ha superato altri approcci dopo aver pesato i pro ei contro. Qualsiasi punto PRO sarebbe accademico al meglio.

CON del Non è un codice linq. Il futuro di TSQL è compilato linq, anche il mio inizia a impararlo.

Il codice compilato è più stabile e più facile da utilizzare. Se eseguo il debug di qualcosa, sono disponibili molte informazioni se utilizzo C # o Java.

È probabile che le procedure memorizzate finiscano con troppe responsabilità, è una buona pratica cercare di mantenere le tue responsabilità a 1.

La mancanza di separazione delle responsabilità porterà a un'applicazione che diventa sempre più difficile su cui lavorare e sempre meno stabile dato che le classi base diventano sempre più grandi.

Se ti piace Microsoft Asp.Net MVC combinato con Entity Framework Code First ti consentirà di creare rapidamente qualsiasi applicazione e non avrai bisogno di alcuna stored procedure.