Quali sono i vantaggi e gli svantaggi di mantenere SQL in Procs memorizzati rispetto al codice [chiuso]

Quali sono i vantaggi / gli svantaggi di mantenere SQL nel codice sorgente C # o in Procs memorizzati? Ne ho discusso con un amico su un progetto open source a cui stiamo lavorando (Forum ASP.NET C #). Al momento, la maggior parte dell'accesso al database viene eseguita creando l'SQL inline in C # e chiamando il DB di SQL Server. Quindi sto cercando di stabilire quale, per questo particolare progetto, sarebbe il migliore.

Finora ho:

Vantaggi per nel codice:

• Più facile da mantenere: non è necessario eseguire uno script SQL per aggiornare le query
• Più facile da trasferire su un altro DB - nessun proc da portare

Vantaggi per Stored Procs:

• Prestazione
• Sicurezza

Non sono un fan delle procedure memorizzate

Le Stored procedure sono PIÙ gestibili perché: * Non è necessario ricompilare l'app C # ogni volta che si desidera modificare alcuni SQL

Finirai comunque per ricompilarlo quando cambiano i tipi di dati, o vuoi restituire una colonna aggiuntiva o qualsiasi altra cosa. Il numero di volte in cui è possibile modificare in modo 'trasparente' l'SQL da sotto l'app è piuttosto piccolo nel complesso

• Si finisce per riutilizzare il codice SQL.

I linguaggi di programmazione, incluso C #, hanno questa cosa meravigliosa, chiamata funzione. Significa che puoi invocare lo stesso blocco di codice da più punti! Sorprendente! È quindi possibile inserire il codice SQL riutilizzabile all'interno di uno di questi o, se si desidera ottenere una tecnologia molto avanzata, è possibile utilizzare una libreria che lo fa per te. Credo che si chiamino Object Relational Mapper e sono abbastanza comuni in questi giorni.

La ripetizione del codice è la cosa peggiore che puoi fare quando stai cercando di creare un'applicazione gestibile!

D'accordo, ecco perché i processi memorizzati sono una cosa negativa. È molto più semplice riformattare e decomporre (suddividere in parti più piccole) il codice in funzioni rispetto a SQL in ... blocchi di SQL?

Hai 4 server web e un sacco di app di Windows che usano lo stesso codice SQL Ora hai capito che c'è un piccolo problema con il codice SQl, quindi preferisci ...... cambiare il proc in 1 posto o spingere il codice a tutti i server web, reinstallare tutte le app desktop (clickonce potrebbe aiutare) su tutte le finestre

Perché le tue app di Windows si collegano direttamente a un database centrale? Sembra un enorme buco nella sicurezza proprio lì, e un collo di bottiglia in quanto esclude la cache sul lato server. Non dovrebbero connettersi tramite un servizio Web o simili ai tuoi server Web?

Quindi, spingere 1 nuovo sproc o 4 nuovi server web?

In questo caso è più semplice inviare un nuovo sproc, ma nella mia esperienza, il 95% delle "modifiche inviate" influisce sul codice e non sul database. Se stai inviando 20 cose ai server web quel mese, e 1 al database, difficilmente perderai molto se invece spingi 21 cose ai server web e zero al database.

Più facilmente revisione del codice.

Puoi spiegare come? Non capisco. In particolare visto che gli sproc probabilmente non sono nel controllo del codice sorgente e quindi non è possibile accedervi tramite browser SCM basati sul Web e così via.

Più contro:

Storedprocs vive nel database, che appare al mondo esterno come una scatola nera. Cose semplici come voler metterle nel controllo del codice sorgente diventano un incubo.

C'è anche il problema del puro sforzo. Potrebbe essere sensato suddividere tutto in un milione di livelli se stai cercando di giustificare al tuo CEO perché costano solo 7 milioni di dollari per costruire alcuni forum, ma altrimenti creare un processo memorizzato per ogni piccola cosa è solo un asino in più per no beneficio.

Questo è in discussione su alcuni altri thread qui al momento. Sono un sostenitore costante delle stored procedure, anche se vengono presentati alcuni buoni argomenti per Linq to Sql.

L'incorporazione di query nel tuo codice ti accoppia strettamente al tuo modello di dati. Le procedure memorizzate sono una buona forma di programmazione contrattuale, il che significa che un DBA ha la libertà di modificare il modello di dati e il codice nella procedura, a condizione che il contratto rappresentato dagli input e dagli output della procedura memorizzata sia mantenuto.

L'ottimizzazione dei database di produzione può essere estremamente difficile quando le query sono nascoste nel codice e non in una posizione centrale e facile da gestire.

[Modifica] Ecco un'altra discussione in corso

Secondo me non puoi votare sì o no su questa domanda. Dipende totalmente dal design della tua applicazione.

Voto totalmente contro l'uso di SP in un ambiente a 3 livelli, dove hai un server delle applicazioni di fronte. In questo tipo di ambiente, il server delle applicazioni è lì per eseguire la logica aziendale. Se si utilizzano inoltre SP, si inizia a distribuire l'implementazione della logica di business su tutto il sistema e diventerà poco chiaro chi sia responsabile di cosa. Alla fine ti ritroverai con un server delle applicazioni che sostanzialmente non farà altro che quanto segue:

(Pseudocode)

Function createOrder(Order yourOrder) 
Begin
  Call SP_createOrder(yourOrder)
End

Quindi alla fine hai il tuo livello intermedio in esecuzione su questo fantastico cluster di 4 Server ognuno dotato di 16 CPU e in realtà non farà nulla! Che spreco!

Se hai un grosso client GUI che si collega direttamente al tuo DB o forse anche più applicazioni è una storia diversa. In questa situazione gli SP possono fungere da una sorta di pseudo livello intermedio che separa l'applicazione dal modello di dati e offre un accesso controllabile.

Vantaggi per nel codice:

• Più facile da mantenere: non è necessario eseguire uno script SQL per aggiornare le query
• Più facile da trasferire su un altro DB - nessun proc da portare

In realtà, penso che tu l'abbia indietro. IMHO, SQL nel codice è difficile da mantenere perché:

• finisci per ripetere te stesso nei blocchi di codice correlati
• SQL non è supportato come linguaggio in molti IDE, quindi hai solo una serie di stringhe controllate senza errori che eseguono attività per te
• le modifiche di un tipo di dati, nome di tabella o vincolo sono molto più diffuse rispetto alla sostituzione di interi database con uno nuovo
• il livello di difficoltà aumenta con l'aumentare della complessità della query
• e testare una query inline richiede la costruzione del progetto

Pensa a Stored Procs come ai metodi che chiami dall'oggetto database: sono molto più facili da riutilizzare, c'è solo un posto da modificare e nel caso in cui cambi provider di DB, le modifiche avvengono nei tuoi Stored Procs e non nel tuo codice .

Detto questo, i guadagni in termini di prestazioni dei proc memorizzati sono minimi come Stu ha detto prima di me e non puoi mettere un punto di interruzione in una procedura memorizzata (ancora).

CON

Trovo che fare un sacco di elaborazioni all'interno di procedure memorizzate renderebbe il tuo server DB un unico punto di inflessibilità, quando si tratta di ridimensionare il tuo atto.

Tuttavia, fare tutto ciò che è difficile nel tuo programma rispetto al sql-server, potrebbe permetterti di ridimensionare di più se hai più server che eseguono il tuo codice. Naturalmente questo non si applica ai proc memorizzati che eseguono solo il normale recupero o aggiornamento, ma a quelli che eseguono più elaborazioni come il loop su set di dati.

PROFESSIONISTI

1. Prestazioni per quello che può valere (evita l'analisi delle query da parte del driver DB / ricreazione del piano ecc.)
2. La manipolazione dei dati non è incorporata nel codice C / C ++ / C #, il che significa che ho un codice di livello inferiore da esaminare. SQL è meno dettagliato e più facile da consultare se elencato separatamente.
3. A causa della separazione, le persone sono in grado di trovare e riutilizzare il codice SQL molto più facilmente.
4. È più facile cambiare le cose quando cambia lo schema: devi solo fornire lo stesso output al codice e funzionerà bene
5. Più facile da trasferire su un database diverso.
6. Posso elencare le singole autorizzazioni sulle mie procedure memorizzate e controllare anche l'accesso a quel livello.
7. Posso profilare il mio codice di query / persistenza dei dati separatamente dal mio codice di trasformazione dei dati.
8. Posso implementare condizioni modificabili nella mia procedura memorizzata e sarebbe facile da personalizzare presso un sito del cliente.
9. Diventa più facile usare alcuni strumenti automatici per convertire insieme il mio schema e le mie istruzioni piuttosto che quando è incorporato nel mio codice dove dovrei cercarli.
10. Garantire le migliori pratiche per l'accesso ai dati è più semplice quando si dispone di tutto il codice di accesso ai dati all'interno di un singolo file: posso verificare le query che accedono alla tabella non performante o che utilizza un livello più elevato di serializzazione o selezionare * nel codice ecc. .
11. Diventa più facile trovare modifiche allo schema / modifiche alla logica di manipolazione dei dati quando tutto è elencato in un unico file.
12. Diventa più facile fare ricerche e sostituire le modifiche su SQL quando si trovano nello stesso posto, ad esempio cambia / aggiungi le istruzioni di isolamento delle transazioni per tutti i processi memorizzati.
13. Io e il ragazzo DBA scopriamo che avere un file SQL separato è più facile / conveniente quando il DBA deve rivedere le mie cose SQL.
14. Infine, non devi preoccuparti degli attacchi di SQL injection perché alcuni membri pigri del tuo team non hanno utilizzato query parametrizzate durante l'utilizzo di sqls incorporato.

Il vantaggio in termini di prestazioni per le stored procedure è spesso trascurabile.

Ulteriori vantaggi per le stored procedure:

• Prevenire il reverse engineering (se creato con Encryption, ovviamente)
• Migliore centralizzazione dell'accesso al database
• Capacità di modificare il modello di dati in modo trasparente (senza dover distribuire nuovi client); particolarmente utile se più programmi accedono allo stesso modello di dati

Cado dal lato del codice . Costruiamo il livello di accesso ai dati che viene utilizzato da tutte le app (sia web che client), quindi è DRY da quella prospettiva. Semplifica la distribuzione del database perché dobbiamo solo assicurarci che gli schemi della tabella siano corretti. Semplifica la manutenzione del codice perché non dobbiamo guardare il codice sorgente e il database.

Non ho molti problemi con l'accoppiamento stretto con il modello di dati perché non vedo dove sia possibile interrompere effettivamente quell'accoppiamento. Un'applicazione e i suoi dati sono intrinsecamente accoppiati.

Procedura di archiviazione.

Se si verifica un errore o la logica cambia un po ', non è necessario ricompilare il progetto. Inoltre, consente l'accesso da diverse fonti, non solo dal punto in cui è stata codificata la query nel progetto.

Non penso sia più difficile mantenere le procedure memorizzate, non dovresti codificarle direttamente nel database ma prima in file separati, quindi puoi semplicemente eseguirle su qualsiasi DB che devi impostare.

Vantaggi per le procedure memorizzate :

Più facilmente revisione del codice.

Meno accoppiato, quindi più facilmente testato.

Più facilmente sintonizzato.

Le prestazioni sono generalmente migliori, dal punto di vista del traffico di rete: se si dispone di un cursore o simili, non ci sono più viaggi nel database

Puoi proteggere l'accesso ai dati più facilmente, rimuovere l'accesso diretto alle tabelle, applicare la sicurezza attraverso i proc - questo ti permette anche di trovare relativamente rapidamente qualsiasi codice che aggiorni una tabella.

Se sono coinvolti altri servizi (come i servizi di reportistica), potrebbe essere più semplice archiviare tutta la logica in una procedura memorizzata, anziché nel codice, e dovendo duplicarla

svantaggi:

Più difficile da gestire per gli sviluppatori: controllo della versione degli script: ognuno ha il proprio database, il sistema di controllo della versione è integrato con il database e l'IDE?

In alcune circostanze, il codice sql creato dinamicamente può avere prestazioni migliori rispetto a un proc memorizzato. Se hai creato un proc memorizzato (diciamo sp_customersearch) che diventa estremamente complicato con dozzine di parametri perché deve essere molto flessibile, puoi probabilmente generare un'istruzione sql molto più semplice nel codice in fase di runtime.

Si potrebbe obiettare che questo sposta semplicemente un po 'di elaborazione da SQL al web server, ma in generale sarebbe una buona cosa.

L'altra cosa grandiosa di questa tecnica è che se stai cercando nel profiler SQL puoi vedere la query che hai generato ed eseguirne il debug molto più facilmente che vedere una chiamata proc memorizzata con 20 parametri in entrata.

Mi piacciono i proc memorizzati, non so quante volte sono stato in grado di apportare una modifica a un'applicazione utilizzando una procedura memorizzata che non ha prodotto alcun tempo morto per l'applicazione.

Grande fan di Transact SQL, l'ottimizzazione di query di grandi dimensioni si è rivelata molto utile per me. Non ho scritto alcun SQL inline da circa 6 anni!

Elencate 2 punti positivi per gli sprocs:

Performance - non proprio. In SQL 2000 o superiore, le ottimizzazioni del piano di query sono piuttosto buone e memorizzate nella cache. Sono sicuro che Oracle ecc. Faccia cose simili. Non credo che ci sia più motivo di sprocs per le prestazioni.

Sicurezza? Perché gli sprocs sarebbero più sicuri? A meno che tu non abbia un database piuttosto non sicuro, comunque, tutto l'accesso sarà dai tuoi DBA o tramite la tua applicazione. Parametrizza sempre tutte le query - non incorporare mai qualcosa dall'input dell'utente e andrà tutto bene.

Questa è la migliore pratica per le prestazioni comunque.

Linq è sicuramente il modo in cui andrei per un nuovo progetto in questo momento. Vedi questo post simile .

@Keith

Sicurezza? Perché gli sprocs sarebbero più sicuri?

Come suggerito da Komradekatz, è possibile impedire l'accesso alle tabelle (per la combinazione nome utente / password che si collega al DB) e consentire solo l'accesso SP. In questo modo, se qualcuno ottiene il nome utente e la password del database, può eseguire SP ma non può accedere alle tabelle o a qualsiasi altra parte del DB.

(Naturalmente l'esecuzione di sprocs può fornire loro tutti i dati di cui hanno bisogno, ma ciò dipenderebbe dagli sprocs disponibili. Dare loro l'accesso alle tabelle consente loro di accedere a tutto.)

Pensare in questo modo

Hai 4 server web e un sacco di app di Windows che usano lo stesso codice SQL Ora hai capito che c'è un piccolo problema con il codice SQl, quindi preferisci ...... cambiare il proc in 1 posto o spingere il codice a tutti i server web, reinstallare tutte le app desktop (clickonce potrebbe aiutare) su tutte le finestre

Preferisco i processi memorizzati

È anche più semplice eseguire test delle prestazioni su un proc, metterlo nell'analizzatore di query impostare statistiche io / time su set showplan_text on e voilà

non è necessario eseguire il profiler per vedere esattamente come viene chiamato

solo i miei 2 centesimi

Preferisco tenerli nel codice (usando un ORM, non in linea o ad hoc), quindi sono coperti dal controllo del codice sorgente senza dover gestire il salvataggio dei file .sql.

Inoltre, le stored procedure non sono intrinsecamente più sicure. Puoi scrivere una cattiva query con uno sproc con la stessa facilità con cui sei in linea. Le query incorporate con parametri possono essere sicure come uno sproc.

Usa il codice della tua app come funziona meglio: gestisci la logica.
Usa il tuo database per quello che fa meglio: archivia i dati.

È possibile eseguire il debug delle stored procedure ma sarà più facile eseguire il debug e mantenere la logica nel codice. Di solito si finisce per ricompilare il codice ogni volta che si cambia il modello di database.

Anche le procedure memorizzate con parametri di ricerca opzionali sono molto carenti perché è necessario specificare in anticipo tutti i parametri possibili e le ricerche complesse a volte non sono possibili perché non è possibile prevedere quante volte un parametro verrà ripetuto nella ricerca.

Quando si tratta di sicurezza, le procedure memorizzate sono molto più sicure. Alcuni hanno sostenuto che comunque l'accesso avverrà tramite l'applicazione. La cosa che molte persone dimenticano è che la maggior parte delle violazioni della sicurezza provengono da un'azienda. Pensa a quanti sviluppatori conoscono il nome utente e la password "nascosti" per la tua applicazione?

Inoltre, come ha sottolineato MatthieuF, le prestazioni possono essere notevolmente migliorate a causa di un minor numero di round trip tra l'applicazione (che si tratti di un desktop o un server Web) e il server di database.

Nella mia esperienza, l'astrazione del modello di dati attraverso le procedure memorizzate migliora notevolmente la manutenibilità. Come qualcuno che ha dovuto mantenere molti database in passato, è un tale sollievo confrontarsi con una modifica del modello richiesta per poter semplicemente cambiare una o due procedure memorizzate e rendere la modifica completamente trasparente a TUTTE le applicazioni esterne. Molte volte la tua applicazione non è l'unica puntata su un database - ci sono altre applicazioni, soluzioni di reporting, ecc. Quindi rintracciare tutti quei punti interessati può essere una seccatura con accesso aperto alle tabelle.

Metterò anche dei controlli nella colonna più per mettere la programmazione SQL nelle mani di coloro che si specializzano in esso e per gli SP che rendono molto più facile isolare e testare / ottimizzare il codice.

L'unico aspetto negativo che vedo è che molte lingue non consentono il passaggio dei parametri della tabella, quindi passare un numero sconosciuto di dati può essere fastidioso e alcune lingue non riescono ancora a gestire il recupero di più set di risultati da una singola procedura memorizzata (sebbene il quest'ultimo non rende gli SP peggiori dell'SQL in linea in questo senso).

Uno dei suggerimenti di una sessione Microsoft TechEd sulla sicurezza a cui ho partecipato, per effettuare tutte le chiamate tramite processi memorizzati e negare l'accesso direttamente alle tabelle. Questo approccio è stato definito come una sicurezza aggiuntiva. Non sono sicuro che ne valga la pena solo per sicurezza, ma se stai già utilizzando proc memorizzati, non potrebbe far male.

Decisamente più facile da mantenere se lo metti in una procedura memorizzata. Se è coinvolta una logica difficile che potenzialmente cambierà in futuro, è sicuramente una buona idea metterlo nel database quando ci sono più client che si connettono. Ad esempio, sto lavorando a un'applicazione in questo momento che ha un'interfaccia Web per l'utente finale e un'applicazione desktop amministrativa, entrambe le quali condividono un database (ovviamente) e sto cercando di mantenere quanta più logica possibile sul database. Questo è un perfetto esempio del principio DRY .

Sono fermamente dalla parte dei proc memorizzati supponendo che tu non imbroglia e usi SQL dinamico nel proc memorizzato. Innanzitutto, l'utilizzo di proc memorizzati consente a dba di impostare le autorizzazioni a livello di proc memorizzato e non a livello di tabella. Ciò è fondamentale non solo per combattere gli attacchi SQL injection, ma anche per impedire agli addetti ai lavori di accedere direttamente al database e di cambiare le cose. Questo è un modo per aiutare a prevenire le frodi. Nessun database che contenga informazioni personali (SSN, numeri di carte di credito, ecc.) O che comunque crei transazioni finanziarie dovrebbe mai essere accessibile se non attraverso procedure rigorose. Se si utilizza qualsiasi altro metodo, si lascia il database aperto agli utenti dell'azienda per creare transazioni finanziarie false o rubare dati che possono essere utilizzati per il furto di identità.

I proc memorizzati sono anche molto più facili da mantenere e ottimizzare le prestazioni rispetto a SQL inviato dall'app. Consentono inoltre al dba di vedere in che modo l'impatto di una modifica strutturale del database avrà sulla modalità di accesso ai dati. Non ho mai incontrato un buon dba che avrebbe consentito l'accesso dinamico al database.

Usiamo le procedure memorizzate con Oracle DB dove lavoro ora. Usiamo anche Subversion. Tutte le procedure memorizzate vengono create come file .pkb e .pks e salvate in Subversion. Ho già eseguito l'SQL in linea ed è una seccatura! Preferisco di gran lunga il modo in cui lo facciamo qui. Creare e testare nuove procedure memorizzate è molto più semplice che farlo nel tuo codice.

C'è un

Registri più piccoli

Un altro pro minore per le procedure memorizzate che non è stato menzionato: quando si tratta di traffico SQL, l'accesso ai dati basato su sp genera molto meno traffico. Ciò diventa importante quando si monitora il traffico per analisi e profilazione: i registri saranno molto più piccoli e leggibili.

Non sono un grande fan delle procedure memorizzate, ma le uso in una condizione:

Quando la query è piuttosto grande, è meglio archiviarla nel database come procedura memorizzata anziché inviarla dal codice. In questo modo, invece di inviare enormi quantità di caratteri stringa dal server delle applicazioni al database, "EXEC SPNAME"verrà inviato solo il comando.

Ciò è eccessivo quando il server database e il web server non si trovano sulla stessa rete (ad esempio, la comunicazione via Internet). E anche se non fosse così, troppi stress significano molta perdita di banda.

Ma amico, sono così terribili da gestire. Li evito il più possibile.

Un proc memorizzato SQL non aumenta le prestazioni della query

Bene, ovviamente, l'utilizzo di stored procedure presenta numerosi vantaggi rispetto alla costruzione di codice SQL nel codice.

1. L'implementazione del codice e SQL diventano indipendenti l'uno dall'altro.
2. Il codice è più facile da leggere.
3. Scrivi una volta, usa più volte.
4. Modifica una volta
5. Non è necessario fornire al programmatore dettagli interni sul database. ecc. ecc.

Le Stored procedure sono PIÙ mantenibili perché:

• Non è necessario ricompilare l'app C # ogni volta che si desidera modificare alcuni SQL
• Si finisce per riutilizzare il codice SQL.

La ripetizione del codice è la cosa peggiore che puoi fare quando stai cercando di creare un'applicazione gestibile!

Cosa succede quando trovi un errore logico che deve essere corretto in più punti? Sei più propenso a dimenticare di cambiare l'ultimo punto in cui hai copiato e incollato il codice.

A mio avviso, le prestazioni e i guadagni di sicurezza sono un ulteriore vantaggio. È ancora possibile scrivere procedure memorizzate SQL non sicure / inefficienti.

Più facile da trasferire su un altro DB - nessun proc da portare

Non è molto difficile eseguire lo scripting di tutte le procedure memorizzate per la creazione in un altro DB. In effetti, è più semplice che esportare le tabelle perché non ci sono chiavi primarie / esterne di cui preoccuparsi.

@Terrapin - sprocs è altrettanto vulnerabile agli attacchi di iniezione. Come ho detto:

Parametrizza sempre tutte le query - non incorporare mai qualcosa dall'input dell'utente e andrà tutto bene.

Questo vale per sprocs e SQL dinamico.

Non sono sicuro che ricompilare la tua app sia un vantaggio. Voglio dire, hai eseguito i tuoi test unitari contro quel codice (sia applicazione che DB) prima di tornare a vivere comunque.

@Guy: sì, hai ragione, gli sprocs ti consentono di controllare gli utenti dell'applicazione in modo che possano solo eseguire lo sproc, non l'azione sottostante.

La mia domanda sarebbe: se tutti gli accessi attraverso la tua app, usando connessioni e utenti con diritti limitati per aggiornare / inserire ecc., Questo livello extra aggiunge sicurezza o amministrazione extra?

La mia opinione è molto quest'ultima. Se hanno compromesso la tua applicazione al punto da poterla riscrivere, hanno molti altri attacchi che possono usare.

Le iniezioni di SQL possono comunque essere eseguite contro quegli sprocs se inline dinamicamente il codice, quindi la regola d'oro si applica ancora, tutti gli input dell'utente devono sempre essere parametrizzati.

Qualcosa che non ho visto menzionato finora: le persone che conoscono meglio il database non sono sempre le persone che scrivono il codice dell'applicazione. Le procedure memorizzate offrono alla gente del database un modo per interfacciarsi con i programmatori che non vogliono davvero imparare molto su SQL. I database di grandi dimensioni, e in particolare quelli legacy, non sono le cose più facili da comprendere completamente, quindi i programmatori potrebbero semplicemente preferire un'interfaccia semplice che dia loro ciò di cui hanno bisogno: lascia che i DBA capiscano come unire le 17 tabelle per farlo accadere.

Detto questo, i linguaggi usati per scrivere le procedure memorizzate (PL / SQL come noto esempio) sono piuttosto brutali. In genere non offrono nessuna delle bellezze che vedresti nei linguaggi imperativi, OOP o funzionali popolari di oggi. Pensa COBOL.

Quindi, attenersi alle procedure memorizzate che si limitano a sottrarre i dettagli relazionali piuttosto che quelli che contengono la logica aziendale.

In genere scrivo il codice OO. Sospetto che probabilmente anche molti di voi lo faranno. In tale contesto, mi sembra ovvio che tutta la logica aziendale, comprese le query SQL, appartenga alle definizioni delle classi. Suddividere la logica in modo tale che parte di essa risieda nel modello a oggetti e parte nel database non è meglio che inserire la logica di business nell'interfaccia utente.

Molto è stato detto nelle risposte precedenti sui vantaggi di sicurezza dei proc memorizzati. Questi rientrano in due grandi categorie:

1) Limitare l'accesso diretto ai dati. Questo è sicuramente importante in alcuni casi e, quando ne incontri uno, i proc memorizzati sono praticamente l'unica opzione. Nella mia esperienza, tuttavia, tali casi sono l'eccezione piuttosto che la regola.

2) SQL injection / query parametrizzate. Questa obiezione è un'aringa rossa. Inline SQL - anche inline SQL generato in modo dinamico - può essere completamente parametrizzato come qualsiasi proc memorizzato e può essere fatto altrettanto facilmente in qualsiasi linguaggio moderno degno di nota. Non c'è alcun vantaggio in entrambi i casi qui. ("Gli sviluppatori pigri potrebbero non preoccuparsi di usare i parametri" non è un'obiezione valida. Se hai sviluppatori nel tuo team che preferiscono concatenare i dati degli utenti nel loro SQL invece di utilizzare i parametri, prima provi a educarli, poi li licenzi se non funziona, proprio come faresti con gli sviluppatori che hanno altre cattive abitudini dannosamente dimostrabili.)

Sono un grande sostenitore del codice su SPROC. Il numero uno dei motivi è mantenere il codice strettamente accoppiato, quindi un secondo vicino è la facilità di controllo del codice sorgente senza molte utility personalizzate per inserirlo.

Nel nostro DAL, se disponiamo di istruzioni SQL molto complesse, generalmente le includiamo come file di risorse e le aggiorniamo in base alle esigenze (potrebbe trattarsi anche di un assembly separato e scambiato per db, ecc ...).

Ciò mantiene il nostro codice e le nostre chiamate sql archiviate nella stessa versione di controllo, senza "dimenticare" di eseguire alcune applicazioni esterne per l'aggiornamento.