Qual è l'argomento a favore e contro l'inserimento del codice nelle stored procedure con l'intenzione di rendere il codice più gestibile (ossia è più facile apportare modifiche alle regole aziendali senza ricompilare il codice)?Le procedure memorizzate sono più facili da mantenere?
A parità di altri fattori, ciò che rende una procedura memorizzata migliore/peggiore per la manutenzione?
Le procedure memorizzate sono una cattiva pratica per una serie di motivi.
Uno dei più significativi è la separazione delle preoccupazioni. Con le stored procedure, hai una logica di business nel livello dati, invece che nel livello di servizio a cui appartiene. Una conseguenza di ciò è che ora avete una sola lingua e una sola lingua in cui implementare la vostra logica aziendale. Con l'arrivo di nuove tecnologie, non hai un buon percorso di migrazione.
Un altro motivo valido per evitare stored procedure è che le stored procedure creano un forte legame tra voi e il fornitore di DB. Sarà molto difficile passare a un altro fornitore di database, mentre la logica di business nel livello di servizio ti consentirà di scambiare facilmente DB. Quindi, le stored procedure offrono un grande vantaggio al fornitore di DB e non tanto per voi.
Avanti, scalabilità. È piuttosto semplice creare servizi in un livello intermedio e distribuirli attraverso un cluster. Come hai intenzione di farlo con una procedura memorizzata? Penso che sarebbe egregiamente difficile raggruppare una stored procedure tra, diciamo, anche otto macchine.
Avanti, integrazione con altri sistemi.Se il tuo sistema sta prelevando dati dal tuo database, facendo affidamento su stored procedure e altri dati da altri sistemi, quella logica dovrà quasi certamente essere in un livello di servizi. Se alcune delle tue logiche di business sono nel livello di servizio e alcune nel livello aziendale, hai qualche problema di manutenzione.
Le stored procedure non contengono la logica aziendale, presentano un'interfaccia di persistenza e nascondono i dettagli di implementazione delle tabelle. Generalmente l'incapsulamento dei dettagli di implementazione è considerato una buona pratica. –
Non sono sicuro che direi che sono una cattiva pratica ... Cerco decisamente di evitarli per alcuni dei motivi che hai menzionato. – mattruma
@Greg - Ho visto stored procedure che contenevano bus. logica. Quindi, per rendere una dichiarazione generale che non lo fa, non suona vero. Se lo fanno, è cattivo. Quando non lo fanno, è meno di un grosso problema. –
Non sto discutendo contro stored procedure, ma suggerirei che sono più difficili da gestire poiché devono essere aggiornate indipendentemente da un aggiornamento dell'applicazione (devono essere memorizzate nel server sql).
È un argomento per applicazioni più grandi e più monolitiche? Altri direbbero "sono più facili da mantenere poiché possono essere aggiornati indipendentemente dall'aggiornamento dell'applicazione", riducendo l'accoppiamento tra i due "(come in qualsiasi altro contesto di elaborazione distribuita) .Dipendenti dalle tue priorità. – dkretz
Questo è anche un vantaggio - come le librerie condivise –
Non credo che la ragione che proponi sia una buona ragione: poiché aiutano a disaccoppiare tra applicazione e livello dati, saranno una buona pratica e ridurranno la riscrittura del codice – Tarik
Probabilmente dipende dal sistema. Per noi, i Procored Stored vengono utilizzati quasi esclusivamente. Abbiamo solo un sito Web, quindi avere le istruzioni SQL in un processo memorizzato rende molto più semplice per il nostro DBA regolare le query e ricreare problemi di prestazioni.
nel progetto in cui lavoro, la maggior parte della manutenzione può essere eseguita cambiando solo le procedure sql. quindi Sì Le procedure di archiviazione sono più controllabili nel mio caso, inoltre hanno prestazioni migliori rispetto all'esecuzione di istruzioni SQL dal codice.
Se il software di base viene distribuito in diversi siti di clienti, è possibile eseguire gran parte della personalizzazione necessaria per ogni singolo cliente tramite il database (viste e stored procedure). Puoi quasi pensare a SP come a INTERFACCIA, passare i dati standard avanti e indietro senza preoccuparti di ciò che accade all'interno.
Questo può, naturalmente, essere gestito anche in altri modi, ad esempio un livello di dati .dll personalizzato per ogni installazione.
In alcuni casi, tuttavia, la personalizzazione in SP anziché in dll consente una personalizzazione più rapida e consente a un DBA o esperto di dati di prendere il sopravvento, lasciando che il programmatore lavori sulla codifica.
Ricordare che il codice nell'SP è disponibile per molte più persone (il cliente, in questo caso) rispetto al codice compilato. Questo può essere buono o cattivo, a seconda della situazione.
In alcune aziende, è politicamente più semplice modificare una stored procedure piuttosto che avere il software reinstallato (che dipende più da chi ha regole più severe, dagli sviluppatori & project manager, dagli amministratori di database o dall'IT/help desk).
Uguale, questa è una cattiva pratica da cambiare al volo, ti ricordi?
Seriamente, fare codice in stored procedure può farti essere sicuro che l'interazione con SQL sia più veloce.
Ma le modifiche sono troppo lontane dal controllo sorgente. (per il controllo del codice sorgente, è necessario esportare, come so)
Le mie stored procedure sono salvate come file di testo in una cartella sotto il controllo di sovversione, vengono modificati, archiviati e quindi caricati in un database di test e testati. Non è necessario esportare nulla per utilizzare il controllo del codice sorgente. Non utilizzare mai Enterprise Manager o simili per apportare le modifiche IMO – MikeW
@ MikeW, idea interessante. – Avram
Anche io - Non lascerei alcun SP vicino al database (di produzione o anche di test) che non era u un VCS; tutto deve essere sotto un VCS. –
Generalmente, questo argomento viene eseguito perché si stanno apportando modifiche ad hoc ai proc memorizzati invece di passare attraverso il controllo della versione, il test, ecc. compilato il codice passerebbe attraverso
Non ho una reazione immediata (a differenza della maggior parte della gente qui), ma dirò che compilare e distribuire una DLL non è molto più difficile in quel tipo di ambiente da cowboy. Oppure puoi usare qualcosa come CS-Script, che ti permette di mantenere file .cs grezzi che vengono compilati su richiesta.
Ho sempre trovato difficoltà nella versione e nel test dei proc memorizzati, mentre la maggior parte del codice è facile. Inoltre, la maggior parte dei linguaggi procedurali RDBMS è piuttosto primitiva, quindi non è l'espressività o le astrazioni che un linguaggio contemporaneo ti dà.
Ovviamente, il controllo della versione è una buona cosa - e, per la maggior parte dei casi, anche alcuni controlli di processo tra gli sviluppatori e la produzione. ;)
reagire a non passare attraverso il controllo del codice sorgente non è un sussulto. –
La gravità della reazione, non la reazione in sé, determina se è un colpo di ginocchio. Molte persone hanno un'opinione immediata e ristretta sull'argomento e si rifiutano di intrattenere qualsiasi nozione alternativa. Quello è un cretino. – Chris
penso un fattore che influenza questo è il numero di clienti in quanto consente di apportare modifiche allo schema senza dover ridistribuire le applicazioni. Per esempio. come DBA trovo molto più facile quando eseguo l'ottimizzazione di SQL, risolvendo bug, ecc. per visitare una stored st anziché i client X per modificare un'istruzione SQL, quando X è un numero grande e "visitarli" significa distribuire una nuova versione dell'app a più workstation.
Fatto correttamente significa anche che lo schema che l'applicazione utilizza può essere diverso dallo schema di archiviazione thedata. Per esempio. Mi piace normalizzare notevolmente lo schema dei dati e fornire un insieme di visualizzazioni e processi memorizzati che l'applicazione utilizza. Lo schema delle app cambia nel tempo con le modifiche al codice dell'app e indipendentemente dallo schema dei dati. Si tratta di un vero e proprio vantaggio con i sistemi multi-applicazione (ad esempio, un app di lettura-scrittura e una web app-sito utilizzando gli stessi dati.)
Spesso v'è un diverso insieme di strumenti e una lingua diversa utilizzata per scrivere proc memorizzati. Questo può essere un ostacolo all'adozione che richiede formazione, sviluppo delle competenze, ecc.
"Spesso esiste un diverso set di strumenti e una lingua diversa utilizzata per scrivere proc memorizzati." Qualcuno avrà bisogno di diventare esperto nella manipolazione del database, sia in strumenti DBMS nuovi e differenti per lo scopo sia in strumenti nuovi e diversi nella lingua. – dkretz
Penso che il principale svantaggio, secondo la mia esperienza, è che pochi sviluppatori con cui ho lavorato erano davvero a proprio agio con SQL (scrivendolo in primo luogo , debugging) Quindi devi essere certo di avere le giuste competenze nel tuo team per poter mantenere un sacco di SQL.
Un grande vantaggio può essere se si dispone di più piattaforme (ad esempio, sia di Windows e applicazioni Web) o si porta una vecchia app a una nuova tecnologia, potrebbe essere possibile riutilizzare le procedure del database.
L'applicazione con cui sto lavorando ha un sacco di funzionalità aziendali nelle stored procedure e probabilmente metà dei bug che risolviamo sono in codice SQL e, se critico, può essere risolto rapidamente sostituendo una stored procedure, al contrario di i bug nel codice dell'applicazione che devono attendere la prossima versione. (il rovescio della medaglia però è che avremmo potuto avere meno bug in primo luogo se non avessimo scritto tanto codice SQL, chissà!)
Perché non cambia la sproc. devi aspettare la prossima versione? –
Beh, suppongo che dovrebbe. Credo che il mio punto fosse che nel nostro caso raramente si diramano e rilasciano un percorso per l'applicazione, ma spesso ripariamo una stored procedure poiché sono relativamente facili da correggere e ridistribuire (nel nostro caso) rispetto al codice dell'applicazione. – MikeW
La mia esperienza è che il controllo del codice sorgente è usato raramente come diligente per mantenere il database così come lo è per il codice dell'applicazione. Certo, probabilmente non è sempre così, ma in 15 anni non l'ho mai visto. Ciò significa che è più probabile che le persone facciano dei cambiamenti in dev, e che il cielo non voglia vivere, i processi di memorizzazione dei database non siano pensati per facilitare la manutenzione perché è troppo semplice.
La mancanza di disciplina non è un motivo per ignorare una tecnologia; non è colpa del database! Seguiamo esattamente le stesse procedure di controllo/revisione/implementazione del codice sorgente per i nostri database come per qualsiasi altro nostro codice. –
Quindi il tuo allora. – Craig
Forse la mia risposta non è stata chiara. Non vi è alcun motivo tecnico che utilizzi stored procs sia meno gestibile e non sia possibile utilizzare il controllo del codice sorgente. Ma in realtà succede solo raramente. – Craig
Preferisco non utilizzare stored procedure perché mi piace rimanere relativamente indipendente dal database. Se arriva un database relazionale migliore, mi piacerebbe avere la possibilità di migrare ad esso. Le procedure memorizzate ti bloccheranno. Detto questo, le uso occasionalmente, possono essere molto potenti.
Pensate delle alternative ...
Quindi prendere in considerazione le vostre esigenze e all'ambiente ...
sono i tuoi sviluppatori familiarità con gli strumenti di gestione di database o avete più programmatori di database e gli amministratori di movimentazione lato db dell'allora recinzione?
È necessario apportare modifiche frequenti allo schema db?
E la sicurezza? Hai bisogno di sicurezza fino al livello utente di un database? Sarebbe più semplice gestire la sicurezza nel codice o nel db?
I tuoi sviluppatori sarebbero più produttivi con un ORM, non dovendo scrivere un DAL per sé o c'è una maggiore complessità che vorresti aggiungere in modo personalizzato al tuo DAL che un ORM non potrebbe fornire?
ecc ...
La gente sta andando ad avere opinioni diverse su se o non proc sono più facili da mantenere in base al tipo di sistemi e ambienti che hanno lavorato in questo sono probabilmente molto diverso dalla tua. Quello che probabilmente dovresti fare invece di domandarti se è più facile da mantenere, è capire se sono adatti ai tuoi bisogni. È davvero una buona domanda, ma forse modifica il tuo post e spiega un po 'di più sul tuo ambiente. e potresti ricevere un consiglio un po 'più mirato.
Una risposta molto buona e bilanciata ... –
Ho fatto la programmazione CRUD come consulente per oltre 10 anni nel mondo degli affari. Posso dirvi che ho inserito tutta la logica di business nelle viste sprocs & il più possibile (e ha senso). I requisiti tendono a cambiare ogni volta che soffia il vento e avere la logica nel database lo rende facile da cambiare e (con commenti decenti) è auto-documentante. Più sproc sono sicuri per la sicurezza e per un facile riutilizzo del codice.
FWIW Uso controllo di origine e test severi su tutti i miei sproc. Fare altrimenti è solo pigrizia.
Cosa succede se la logica di business si basa su un servizio esterno (servizio Web o configurazione del file system)? Inoltre cosa fai se l'applicazione deve funzionare in un ambiente disconnesso? –
ecco perché sono stati inventati i parametri e Biztalk 8D –
Non vedo come questo possa risolvere il problema di dover chiamare un servizio web da un sproc. che è quello a cui mi riferivo. –
Le stored procedure sono una buona idea per una serie di motivi:
Mettendo la logica di business più vicino ai dati, è in grado di avere un numero qualsiasi di interfaccia client ai dati. Si può inizialmente progettare il front-end per un sito Web, ma ora vogliono i report. Nessun problema, la logica di business è accanto ai dati. Apri le API, metti un servizio web di fronte alla procedura. Vuoi usare la nuova lingua più calda, vai avanti. La logica aziendale è accanto ai dati.
Un altro motivo per utilizzare stored procedure è che crea un forte legame tra voi e il database scelto. In questo modo, puoi sfruttare la funzionalità integrata del DB che stai pagando (o utilizzare in caso di open source). E indovina un po ', se provi a rendere indipendente la tua DB di applicazione, probabilmente avrai un certo numero di bug difficili da rintracciare. Read consistency works differently on each vendor's database.
È possibile sfruttare la scalabilità incorporata del database (cluster, RAC, ma la implementano). Non c'è bisogno di scrivere il tuo.
È più difficile scrivere codice che non usi le variabili di binding (google soft parses vs hard parses se avete bisogno di maggiori informazioni su questo).
Controllo versione - le aziende Ho sempre utilizzato il controllo della versione per le stored procedure. Normalmente si scrivono stored procedure in alcuni editor. La maggior parte degli editori ora ha integrato il supporto per almeno uno dei principali sistemi di controllo delle versioni.
Il codice esterno deve trascinare i dati attraverso la rete e quindi lavorare con esso.
Infine, non tutti i linguaggi procedurali vengono creati allo stesso modo. MySQL ha appena rilasciato la possibilità di utilizzare le stored procedure e ti offre un certo numero di lingue che puoi usare incluso il loro. Dubito che siano in grado di resistere ai server Oracle o SQl. Non ho intenzione di entrare in chi è il migliore perché non sono un esperto in tutto tranne Oracle. Il PL/SQL di Oracle ha un sacco di funzionalità ottimizzate nel kernel del DB. Sono certo che anche MS SQL lo fa altrettanto bene agli altri.
Spero che questo sia utile (e ha senso - lunga giornata).
L'editor di SQL Server non supporta il controllo del codice sorgente. Neanche il server stesso. –
Ma lo fa Visual Studio. A meno che non mi sbagli, puoi scrivere le stored procedure in questo. – user60890
Sono contrario alla logica di business contro i dati. Ho visto molte stored procedure con molta logica aziendale e sono criptici. SQL (o TSQL) non è un linguaggio creato per scrivere la tua logica aziendale. Ora, si cita, che MySQL consente di scrivere stored procedure in lingue diverse. Questo potrebbe fare la differenza. Microsoft SQL Server 2005+ consente anche di scrivere sproc in .NET (CLR) ma non ho visto molto uso o blog/post su di esso. Non sono sicuro del motivo per cui Microsoft non lo promuova tanto, perché penso che sarebbe il perfetto equilibrio tra SQL dinamico e stored procedure. –
Le stored procedure offrono numerosi vantaggi rispetto alla conservazione delle query nell'applicazione e molte sono già state citate.
Le stored procedure fungono da livello di astrazione tra l'applicazione ei dati e gli strati di astrazione raramente sono una cosa negativa.
È possibile ottenere un determinato livello di riutilizzo se si dispone di operazioni di database a cascata. La procedura Delete_Employee, ad esempio, può chiamare la procedura Delete_Address in una transazione e fare molte altre cose, con una singola richiesta di database dall'applicazione.
Un livello di Visualizzazioni sotto le stored procedure può essere utilizzato per isolare l'applicazione dalle modifiche dello schema e dall'ottimizzazione delle prestazioni di query/join.
Un livello di stored procedure è una parte importante di un'architettura e di un framework aziendali solidi. Queste stored procedure non dovrebbero contenere alcuna logica di business, ovviamente, dovrebbero solo passare attraverso i dati e non manipolarli.
Per realizzare questi vantaggi, una buona disciplina è al fine di mantenere la coerenza e la stessa granularità in tutte le procedure di un'applicazione. Ho lavorato su applicazioni con molti 100 di procedure. Se tutte queste query fossero state incluse nel codice, sarebbe stato molto più difficile, se non impossibile, implementare la sicurezza a livello di dati. Processi memorizzati possono essere facilmente generati. Sento che la produttività generale è più alta con le stored procedure che senza. E, naturalmente, le stored procedure possono essere visualizzate nel controllo del codice sorgente, come nel caso di tutti gli altri oggetti del database.
+1 perché qualcuno ha bisogno di qualche aiuto per i nemici. –
SQL può essere inserito nel controllo del codice sorgente ma i fatti difficili e veloci sono che è così facile da modificare sul database stesso che molto raramente funziona. Gli script nel controllo del codice sorgente non saranno più aggiornati. –
Non è possibile giustificare una progettazione dell'applicazione scadente con pratiche di gestione del codice inadeguate. – cdonner
Ho ancora una cosa sul controllo della versione. Durante il mio ultimo lavoro, ho aggiunto una confezione di terze parti che veniva eseguita ogni giorno e memorizzava una copia del DDL o del codice di ciascun oggetto se è stato modificato dall'ultima volta in cui è stato eseguito il backup. Si trattava di stored procedure, quindi avrebbe potuto essere eseguito manualmente o tramite trigger, come mai volevi che fosse eseguito. Di per sé è un sistema di controllo della versione.
Era uno strumento piuttosto carino ed era solo di circa $ 200. È arrivato anche con uno strumento diff per mostrarti cosa è cambiato.
Siamo passati da utilizzare sprocs ad un DAL generato per la logica di business basato su codice per un bel paio di motivi:
Dipende davvero da quanto bene vengono scritte le stored procedure, vero? T-SQL e PL-SQL possono essere altrettanto difficili da mantenere come C# o COBOL se il professionista non sta codificando con qualche pensiero e cura.
Uno dei miglioramenti recenti su cui ho lavorato, ho intenzionalmente inserito la funzionalità in un processo memorizzato, principalmente perché volevo che la funzionalità fosse più facile da consultare, molto meno da mantenere (la procedura memorizzata può essere richiamata dal anche il livello del cliente, se avessi messo la logica in un livello diverso, non sarebbe vero). Pensavo di aver fatto un buon lavoro rendendo il PL-SQL abbastanza modulare, ma quando TOAD lo ha analizzato, 3 sezioni su 4 hanno ottenuto buoni voti, e l'ultima è stata martellata per l'alta complessità ciclomatica. Heh, penso di aver appena dimostrato il mio punto di vista!
Alcuni sostengono che la logica aziendale non ha spazio nelle stored procedure e risulta in sistemi non gestibili. Vorrei sottolineare che questi argomenti provengono principalmente dai punti di vista di DDD e N-Tier che cercano di ospitare tutte le logiche di business in una regione specifica all'interno del livello dell'applicazione. Mentre questo è un obiettivo degno, ci sono altri punti di vista là fuori che vale la pena considerare. Gli SP possono anche fare molto di più della semplice logica aziendale.
Incidentalmente, il mondo Oracle crede che la sua migliore pratica sia quella di avere tutte le logiche di business nel codice PL/SQL sul DB, e sanno una cosa o due sui database relazionali!
Considerare questi usi della SP:
Performance. È spesso utile eseguire più istruzioni SQL in un SP e quindi evitare che l'applicazione effettui più round trip nel DB, con conseguenti miglioramenti delle prestazioni a volte considerevoli.
Gestione modifiche. Gli SP sono semplici da mantenere e modificare, a condizione di disciplinare il controllo della versione e il processo di distribuzione.
Gli SP possono essere rilasciati per sistemi di produzione dal vivo senza un'interruzione, che può rappresentare un notevole vantaggio nelle operazioni 24/7. Ovviamente è ancora necessario uno stretto controllo sul processo di rilascio.
Strato di astrazione. Gli SP possono astrarre i dettagli dello schema DB dall'applicazione, a condizione che tutte le interazioni app/db siano tramite SP. Questo può essere un concetto molto potente. Considera che la durata di vita del DB supererà spesso l'app - le app vanno e vengono, e vengono riscritte ogni tanto con le ultime tecnologie e modelli di architettura, ma i dati preziosi rimangono nello stesso vecchio DB relazionale per eoni. Spesso, le app multiple sono sviluppate sullo stesso DB, anche se questo non è mai stato l'intento originale. Gli SP in questi scenari vengono utilizzati per fornire un'API stretta e ben definita tra app e DB, che può essere controllata con attenzione per garantire interazioni coerenti con più app e persino più versioni della stessa app.
Questa separazione di problemi tra schema db e app lascia ai programmatori di applicazioni liberi di fare ciò che sanno fare meglio, lasciando al DBA la mano libera per migliorare lo schema nel tempo senza rompere le app.
Indipendentemente dal modello di architettura utilizzato, gli SP possono svolgere un ruolo prezioso. Non escludere quindi alcun progetto e, come qualsiasi altro strumento, utilizzarlo dove ha senso.
Ho votato per le ragioni in Gestione modifiche e Livello di astrazione. L'argomento Prestazioni non si applica in quanto è possibile eseguire più istruzioni SQL in una singola "chiamata" in questi giorni. –
Più facile allora? Questa domanda è priva di significato senza sapere cosa confrontare. – SquareCog