Domanda

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

Finora ho:

Vantaggi per in Code:

  • Più facile da mantenere: non è necessario eseguire uno script SQL per aggiornare le query
  • Più facile da trasferire su un altro DB: nessuna procedura da trasferire

Vantaggi per le procedure memorizzate:

  • Prestazione
  • Sicurezza
È stato utile?

Soluzione

Non sono un fan delle procedure memorizzate

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

Finirai per ricompilarlo comunque quando i tipi di dati cambiano, o vuoi restituire una colonna in più, o altro.Il numero di volte in cui puoi modificare in modo "trasparente" l'SQL da sotto la tua app è nel complesso piuttosto ridotto

  • Alla fine riutilizzi il codice SQL.

I linguaggi di programmazione, incluso C#, hanno questa cosa straordinaria chiamata funzione.Significa che puoi invocare lo stesso blocco di codice da più posti!Sorprendente!Puoi quindi inserire il codice SQL riutilizzabile all'interno di uno di questi o, se vuoi ottenere una tecnologia davvero avanzata, puoi utilizzare una libreria che lo fa per te.Credo che si chiamino Object Relational Mapper e siano piuttosto comuni al giorno d'oggi.

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

D'accordo, ecco perché gli storedproc sono una brutta cosa.È molto più semplice eseguire il refactoring e scomporre (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 Windows che utilizzano lo stesso codice SQL Ora ti sei reso conto che c'è un piccolo problema con il codice SQL, quindi preferisci......cambia la procedura in 1 posto o invia il codice a tutti i server web, reinstalla tutte le app desktop (fare clic una volta potrebbe aiutare) su tutte le finestre di Windows

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

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

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

Codice più facilmente revisionabile.

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

Altri svantaggi:

Gli Storedproc risiedono nel database, che al mondo esterno appare come una scatola nera.Cose semplici come voler metterli sotto il controllo del codice sorgente diventano un incubo.

C'è anche il problema dello sforzo puro e semplice.Potrebbe avere senso scomporre tutto in a milioni di livelli se stai cercando di giustificare al tuo CEO perché gli è costato solo 7 milioni di dollari costruire alcuni forum, ma per il resto creare uno storedproc per ogni piccola cosa è solo un lavoro da asino extra senza alcun vantaggio.

Altri suggerimenti

Se ne sta discutendo in qualche altro thread qui attualmente.Sono un sostenitore coerente delle procedure memorizzate, sebbene vengano presentati alcuni buoni argomenti a favore di Linq to Sql.

Incorporare le query nel tuo codice ti associa strettamente al tuo modello di dati.Le procedure memorizzate sono una buona forma di programmazione contrattuale, nel senso che un DBA ha la libertà di modificare il modello di dati e il codice nella procedura, purché venga mantenuto il contratto rappresentato dagli input e dagli output della procedura memorizzata.

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

[Modifica] Eccone un altro discussione attuale

Secondo me non si può votare sì o no a questa domanda.Dipende totalmente dal design della tua applicazione.

Voto totalmente contro l'uso degli SP in un ambiente a 3 livelli, dove hai di fronte un server delle applicazioni.In questo tipo di ambiente il tuo server delle applicazioni è lì per eseguire la tua logica aziendale.Se utilizzi inoltre gli SP, inizi a distribuire l'implementazione della logica aziendale in tutto il tuo sistema e diventerà molto poco chiaro chi è 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, ciascuno 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 magari anche a più applicazioni è una storia diversa.In questa situazione gli SP possono fungere da sorta di pseudo livello intermedio che disaccoppia l'applicazione dal modello dati e offre un accesso controllabile.

Vantaggi per in Code:

  • Più facile da mantenere: non è necessario eseguire uno script SQL per aggiornare le query
  • Più facile da trasferire su un altro DB: nessuna procedura da trasferire

In realtà, penso che tu lo abbia fatto al contrario.IMHO, SQL nel codice è difficile da mantenere perché:

  • finisci per ripeterti in 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 a un tipo di dati, a un nome di tabella o a un vincolo sono molto più diffuse rispetto alla sostituzione di un intero database con uno nuovo
  • il tuo livello di difficoltà aumenta man mano che la tua query diventa più complessa
  • e testare una query in linea richiede la creazione del progetto

Pensa agli Stored Procs come 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 DB, le modifiche avvengono nei tuoi Stored Procs e non nel tuo codice .

Detto questo, i miglioramenti in termini di prestazioni dei processi memorizzati sono minimi come ha detto Stu prima di me e non è possibile inserire un punto di interruzione in una procedura memorizzata (ancora).

CON

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

Tuttavia, facendo tutto questo crunch nel tuo programma invece che nel server SQL, Potrebbe ti consente di scalare di più se disponi di più server che eseguono il tuo codice.Ovviamente questo non si applica ai processi memorizzati che eseguono solo il normale recupero o aggiornamento, ma a quelli che eseguono più elaborazioni come il looping sui set di dati.

PROFESSIONISTI

  1. Prestazioni per quello che potrebbero 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 meno codice di basso livello da esaminare.SQL è meno dettagliato e più facile da consultare se elencato separatamente.
  3. Grazie alla separazione le persone sono in grado di trovare e riutilizzare il codice SQL molto più facilmente.
  4. È più semplice cambiare le cose quando cambia lo schema: devi solo fornire lo stesso output al codice e funzionerà perfettamente
  5. Più facile da trasferire su un database diverso.
  6. Posso elencare le autorizzazioni individuali sulle mie procedure memorizzate e controllare l'accesso anche 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 personalizzarla presso la sede del cliente.
  9. Diventa più semplice utilizzare alcuni strumenti automatizzati per convertire insieme il mio schema e le mie istruzioni piuttosto che quando sono incorporati nel mio codice dove dovrei scovarli.
  10. Garantire le migliori pratiche per l'accesso ai dati è più semplice quando hai tutto il codice di accesso ai dati all'interno di un singolo file: posso verificare la presenza di query che accedono alla tabella non performante o a quella che utilizza un livello di serializzazione più elevato o selezionare * nel codice, ecc. .
  11. Diventa più semplice trovare modifiche allo schema/modifiche alla logica di manipolazione dei dati quando tutto è elencato in un unico file.
  12. Diventa più semplice eseguire la ricerca e la sostituzione delle modifiche su SQL quando si trovano nello stesso posto, ad es.modificare/aggiungere istruzioni di isolamento della transazione per tutte le procedure archiviate.
  13. Io e il DBA riteniamo che avere un file SQL separato sia più facile/conveniente quando il DBA deve rivedere il mio materiale SQL.
  14. Infine, non devi preoccuparti degli attacchi SQL injection perché alcuni membri pigri del tuo team non hanno utilizzato query parametrizzate quando utilizzano SQL incorporato.

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

Ulteriori vantaggi per le procedure memorizzate:

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

Cado sul codice lato.Creiamo un livello di accesso ai dati utilizzato da tutte le app (sia Web che client), quindi è DRY da quel punto di vista.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 al codice sorgente e al database.

Non ho molti problemi con lo stretto accoppiamento con il modello di dati perché non vedo dove sia possibile rompere davvero quell'accoppiamento.Un'applicazione e i relativi dati sono intrinsecamente accoppiati.

Procedura di archiviazione.

Se si verifica un errore o la logica cambia leggermente, non è necessario ricompilare il progetto.Inoltre, consente l'accesso da diverse origini, non solo da quella in cui hai codificato la query nel tuo progetto.

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

Vantaggi per le procedure memorizzate:

Codice più facilmente revisionabile.

Meno accoppiato, quindi più facilmente testabile.

Sintonizzazione più semplice.

Le prestazioni sono generalmente migliori, dal punto di vista del traffico di rete: se hai 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, rafforzare la sicurezza tramite le procedure: questo ti consente anche di trovare in tempi relativamente brevi qualsiasi codice che aggiorna una tabella.

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

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 processo memorizzato (diciamo sp_customersearch) che diventa estremamente complicato con dozzine di parametri perché deve essere molto flessibile, probabilmente puoi generare un'istruzione SQL molto più semplice nel codice in fase di esecuzione.

Si potrebbe sostenere che ciò sposti semplicemente parte dell'elaborazione da SQL al server Web, ma in generale sarebbe una buona cosa.

L'altro aspetto positivo 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 entrare una chiamata proc memorizzata con 20 parametri.

Mi piacciono le procedure memorizzate, 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 di inattività dell'applicazione.

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

Elenca 2 punti pro per sprocs:

Prestazioni: non proprio.In SQL 2000 o versioni successive le ottimizzazioni del piano di query sono piuttosto buone e memorizzate nella cache.Sono sicuro che Oracle ecc. faccia cose simili.Non penso che ci sia più motivo di utilizzare gli sproc per le prestazioni.

Sicurezza?Perché gli sproc dovrebbero essere più sicuri?A meno che tu non disponga di un database piuttosto non protetto, tutto l'accesso avverrà dai tuoi DBA o tramite la tua applicazione.Parametrizza sempre tutte le query: non incorporare mai qualcosa dall'input dell'utente e starai bene.

Questa è comunque la migliore pratica per le prestazioni.

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

@Keith

Sicurezza?Perché gli sproc dovrebbero essere più sicuri?

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

(Ovviamente l'esecuzione di sproc può fornire loro tutti i dati di cui hanno bisogno, ma ciò dipenderebbe dagli sproc disponibili.Dare loro l'accesso alle tabelle dà loro accesso a tutto.)

Pensare in questo modo

Hai 4 server web e un mucchio di app Windows che usano lo stesso codice SQL Ora ti sei reso conto che c'è un piccolo problema con il codice SQl così fai tu preferi......Cambia il proc in 1 posto o Invia il codice a tutti i server Web, reinstalla tutte le app desktop (ClickOnce potrebbe aiutare) su tutte le caselle di Windows

Preferisco i processi memorizzati

È anche più facile eseguire test delle prestazioni rispetto a un processo, inserirlo nell'analizzatore di query Imposta statistiche I/O su Accendi showplan_text e voilà

non è necessario eseguire profiler per vedere esattamente cosa viene chiamato

solo i miei 2 centesimi

Preferisco mantenerli nel codice (utilizzando un ORM, non in linea o ad hoc) in modo che siano coperti dal controllo del codice sorgente senza dover occuparsi del salvataggio dei file .sql.

Inoltre, le procedure memorizzate non sono intrinsecamente più sicure.Puoi scrivere una query errata con uno sproc con la stessa facilità con cui la inline.Le query in linea con parametri possono essere sicure quanto una sproc.

Utilizza il codice dell'app come sa fare meglio:gestire la logica.
Utilizza il tuo database per ciò che sa fare meglio:immagazzina dati.

È possibile eseguire il debug delle procedure memorizzate, ma sarà più semplice eseguire il debug e mantenere la logica nel codice.Di solito finirai di ricompilare il codice ogni volta che cambi il modello di database.

Anche le procedure memorizzate con parametri di ricerca opzionali sono molto inefficienti 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 tutto l’accesso avverrà comunque tramite l’applicazione.Ciò che molte persone dimenticano è che la maggior parte delle violazioni della sicurezza provengono dall’interno dell’azienda.Pensa a quanti sviluppatori conoscono il nome utente e la password "nascosti" della tua applicazione?

Inoltre, come ha sottolineato MatthieuF, le prestazioni possono essere notevolmente migliorate grazie a un minor numero di viaggi di andata e ritorno tra l'applicazione (sia su un desktop che su un server Web) e il server del database.

Nella mia esperienza, anche l'astrazione del modello dati tramite procedure memorizzate migliora notevolmente la manutenibilità.Essendo qualcuno che ha dovuto mantenere molti database in passato, è un tale sollievo quando si confronta con una modifica del modello richiesta poter semplicemente modificare una o due procedure memorizzate e avere la modifica completamente trasparente per 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 i punti interessati può essere una seccatura con accesso libero alle tabelle.

Inserirò anche dei controlli nella colonna più per mettere la programmazione SQL nelle mani di coloro che sono specializzati in essa e per gli SP che rendono molto più semplice isolare e testare/ottimizzare il codice.

L'unico lato negativo che vedo è che molti linguaggi non consentono il passaggio di parametri di tabella, quindi passare valori di dati con un numero sconosciuto può essere fastidioso e alcuni linguaggi 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 sotto questo aspetto).

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

Decisamente più facile da mantenere se lo inserisci in una procedura memorizzata.Se è coinvolta una logica difficile che potrebbe potenzialmente cambiare in futuro, è sicuramente una buona idea inserirla nel database quando si collegano più client.Ad esempio, sto lavorando su un'applicazione in questo momento che ha un'interfaccia web per l'utente finale e un'applicazione desktop amministrativa, che condividono entrambe un database (ovviamente) e sto cercando di mantenere quanta più logica possibile nel database.Questo è un perfetto esempio di Principio SECCO.

Sono fermamente dalla parte dei processi memorizzati presupponendo che tu non imbrogli e utilizzi SQL dinamico nel processo memorizzato.Innanzitutto, l'utilizzo delle procedure memorizzate consente al dba di impostare le autorizzazioni a livello di procedure memorizzate 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 modificare le cose.Questo è un modo per aiutare a prevenire le frodi.Non si dovrebbe mai accedere a nessun database che contenga informazioni personali (SSN, numeri di carta di credito, ecc.) o che comunque crei transazioni finanziarie se non attraverso procedure memorizzate.Se utilizzi qualsiasi altro metodo, lasci il tuo database aperto alle persone dell'azienda per creare transazioni finanziarie false o rubare dati che possono essere utilizzati per il furto di identità.

I processi archiviati sono anche molto più facili da mantenere e ottimizzare le prestazioni rispetto a SQL inviato dall'app.Consentono inoltre al dba di vedere quale sarà l'impatto di un cambiamento strutturale del database sul modo in cui si accede ai dati.Non ho mai incontrato un buon dba che consentisse l'accesso dinamico al database.

Utilizziamo procedure memorizzate con DB Oracle dove lavoro ora.Usiamo anche Subversion.Tutte le procedure memorizzate vengono create come file .pkb e .pks e salvate in Subversion.Ho già eseguito 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 codice.

C'è un

Tronchi più piccoli

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

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

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

Ciò è eccessivo quando il server del database e il server Web non si trovano sulla stessa rete (ad esempio, comunicazione Internet).E anche se così non fosse, troppo stress significa molta larghezza di banda sprecata.

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

Una procedura memorizzata SQL non aumenta le prestazioni della query

Ovviamente l'utilizzo di procedure memorizzate presenta numerosi vantaggi rispetto alla costruzione di 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 e usa molte volte.
  4. Modifica una volta
  5. Non è necessario fornire dettagli interni al programmatore sul database.ecc, ecc.

Le procedure memorizzate lo sono DI PIÙ mantenibile perché:

  • Non è necessario ricompilare l'app C# ogni volta che si desidera modificare parte del codice SQL
  • Alla fine riutilizzi il codice SQL.

La ripetizione del codice è il peggio cosa che puoi fare quando stai cercando di creare un'applicazione manutenibile!

Cosa succede quando trovi un errore logico che deve essere corretto in più punti?È più probabile che dimentichi di modificare l'ultimo punto in cui copi e incolli il codice.

A mio parere, i miglioramenti in termini di prestazioni e sicurezza sono un ulteriore vantaggio. È comunque possibile scrivere procedure memorizzate SQL non sicure/inefficienti.

Più facile da trasferire su un altro DB: nessuna procedura da trasferire

Non è molto difficile scrivere tutte le procedure memorizzate per la creazione in un altro DB.In effetti, lo è Più facile che esportare le tue tabelle perché non ci sono chiavi primarie/estranee di cui preoccuparsi.

@Terrapin: gli sproc sono altrettanto vulnerabili agli attacchi di iniezione.Come ho detto:

Parametrizza sempre tutte le query: non incorporare mai qualcosa dall'input dell'utente e starai bene.

Questo vale per sproc e SQL dinamico.

Non sono sicuro che non ricompilare la tua app sia un vantaggio.Voglio dire, hai eseguito i test unitari su quel codice (sia applicazione che DB) prima di tornare comunque in funzione.


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

La mia domanda sarebbe:se tutti accedono tramite la tua app, utilizzando connessioni e utenti con diritti limitati di aggiornamento/inserimento, ecc., questo livello aggiuntivo aggiunge sicurezza o amministrazione aggiuntiva?

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

È ancora possibile eseguire iniezioni SQL contro tali sproc se inlineano dinamicamente il codice, quindi si applica ancora la regola d'oro, tutto l'input dell'utente deve sempre essere parametrizzato.

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 agli addetti al database un modo per interfacciarsi con i programmatori che in realtà non vogliono imparare molto su SQL.I database di grandi dimensioni, e soprattutto quelli legacy, non sono le cose più facili da comprendere completamente, quindi i programmatori potrebbero semplicemente preferire un'interfaccia semplice che offra loro ciò di cui hanno bisogno:lascia che i DBA capiscano come unire i 17 tavoli per far sì che ciò accada.

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

Pertanto, attenersi alle procedure memorizzate che si limitano ad astrarre i dettagli relazionali anziché a quelle che contengono la logica aziendale.

Generalmente scrivo codice OO.Sospetto che anche la maggior parte di voi probabilmente lo faccia.In questo contesto, mi sembra ovvio che tutta la logica aziendale, comprese le query SQL, appartenga alle definizioni di classe.Suddividere la logica in modo che una parte risieda nel modello a oggetti e una parte nel database non è migliore che inserire la logica aziendale nell'interfaccia utente.

Molto è stato detto nelle risposte precedenti sui vantaggi in termini di sicurezza dei processi archiviati.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 processi memorizzati sono praticamente la tua unica opzione.Secondo la mia esperienza, tuttavia, questi casi rappresentano l’eccezione piuttosto che la regola.

2) Query SQL injection/parametrizzate.Questa obiezione è una falsa pista.L'SQL in linea, anche l'SQL in linea generato dinamicamente, può essere completamente parametrizzato come qualsiasi procedura memorizzata e può essere eseguito altrettanto facilmente in qualsiasi linguaggio moderno degno di nota.In ogni caso qui non vi è alcun vantaggio.("Gli sviluppatori pigri potrebbero non preoccuparsi di usare i parametri" non è un'obiezione valida.Se nel tuo team ci sono sviluppatori che preferiscono semplicemente concatenare i dati utente nel loro SQL invece di utilizzare parametri, prima provi a educarli, poi li licenzi se non funziona, proprio come faresti con gli sviluppatori che hanno altri cattiva abitudine palesemente dannosa.)

Sono un grande sostenitore del codice rispetto a SPROC.Il motivo numero uno è mantenere il codice strettamente accoppiato, quindi il secondo è la facilità del controllo del codice sorgente senza molte utilità personalizzate per inserirlo.

Nel nostro DAL se abbiamo istruzioni SQL molto complesse, generalmente le includiamo come file di risorse e le aggiorniamo secondo necessità (anche questo potrebbe essere un assembly separato e scambiato per db, ecc...).

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top