Stored procedure o query in linea?

Question

Prima di tutto c'è un domanda parziale riguardo a questo, ma non è esattamente quello che sto chiedendo, quindi, abbi pazienza e provaci.

La mia domanda è, dopo aver visto cosa SubSonic e gli eccellenti video di Rob Connery che devo chiedere: Usiamo uno strumento come questo e facciamo query in linea o dobbiamo fare le query usando una chiamata alla procedura memorizzata?

Non voglio minimizzare nessun lavoro di Rob (che penso sia fantastico) ma voglio solo la tua opinione su questa causa, devo iniziare un nuovo progetto e sono nel mezzo della linea; dovrei usare SubSonic (o altri strumenti simili, come NHibernate) o semplicemente continuerò il mio metodo che è sempre chiamato procedura memorizzata anche se è semplice come

Select this, that from myTable where myStuff = StackOverflow;

Answer 1

Non deve essere l'uno o l'altro. Se si tratta di una query semplice, utilizzare lo strumento di query SubSonic. Se è più complesso, utilizzare una procedura memorizzata e caricare una raccolta o creare un set di dati dai risultati.

Vedi qui: Quali sono i vantaggi e gli svantaggi di mantenere SQL in Proc. Memorizzati rispetto al codice e qui SubSonic e Stored procedure

Answer 2

Vedi le risposte qui e qui . Uso sprocs ogni volta che posso, tranne quando la burocrazia significa che ci vuole una settimana per farlo nel database.

Answer 3

Le procedure memorizzate sono gold quando si hanno diverse applicazioni che dipendono dallo stesso database. Ti consente di definire e mantenere la logica della query una volta, piuttosto che in diversi punti.

D'altra parte, è abbastanza facile per le stesse procedure memorizzate diventare un grosso pasticcio confuso nel database, poiché la maggior parte dei sistemi non ha un buon metodo per organizzarli logicamente. E possono essere più difficili da versione e tenere traccia delle modifiche.

Answer 4

Non seguirò personalmente regole rigide. Sicuramente durante le fasi di sviluppo, vuoi essere in grado di cambiare rapidamente le tue domande in modo da poterle incorporare.

In seguito, passerei alle stored procedure perché offrono i seguenti due vantaggi. Sono sicuro che ce ne sono altri, ma questi due mi hanno conquistato.

1 / Le procedure memorizzate raggruppano i dati e il codice per manipolare / estrarre tali dati in un punto. Questo rende la vita del tuo DBA molto più semplice (supponendo che la tua app sia abbastanza grande da giustificare un DBA) poiché può ottimizzare in base a fattori noti.

Uno dei maggiori bugbear di un DBA sono le query ad hoc (specialmente da clown che non sanno cos'è una scansione completa della tabella). Gli amministratori di database preferiscono disporre di query coerenti su cui ottimizzare il database.

2 / Le procedure memorizzate possono contenere la logica che è meglio lasciare nel database. Ho visto procs memorizzati in DB2 / z con molte dozzine di linee, ma tutto ciò che il client deve codificare è una singola riga come "dammi quella lista".

Perché la logica di " quella lista " è archiviato nel database, i DBA possono modificare il modo in cui sono archiviati ed estratti a piacimento senza senza compromettere o modificare il codice client. Questo è simile all'incapsulamento che ha reso i linguaggi orientati agli oggetti "più puliti" di quanto non fosse prima

Answer 5

Ho fatto un mix di query in linea e stored procedure. Preferisco di più dell'approccio stored procedure / view in quanto guadagna un bel posto per voi di apportare una modifica, se necessario. Quando hai query in linea devi sempre andare e cambiare il codice per cambiare una query in linea e quindi ripetere il rollback dell'applicazione. Potresti anche avere la query inline in più posizioni, quindi dovresti cambiare molto più codice rispetto a una procedura memorizzata.

Quindi di nuovo se devi aggiungere un parametro a una procedura memorizzata, stai comunque cambiando molto codice.

Un'altra nota è la frequenza con cui i dati cambiano dietro la procedura memorizzata, dove lavoro abbiamo tabelle di terze parti che possono essere suddivise in tabelle normalizzate o una tabella diventa obsoleta. In tal caso, una procedura / vista memorizzata potrebbe ridurre al minimo l'esposizione a tale modifica.

Ho anche scritto un'intera applicazione senza stored procedure. Aveva tre classi e 10 pagine, non ne valeva la pena. Penso che arrivi un momento in cui sia eccessivo, o possa essere giustificato, ma dipende anche dalla tua opinione personale e dalle tue preferenze.

Answer 6

Accederai al tuo database solo da quell'unica applicazione?

Altrimenti, probabilmente stai meglio usando le procedure memorizzate in modo da poter avere un'interfaccia coerente con il tuo database.

Ci sono costi significativi per la distribuzione della tua applicazione se devi apportare una modifica?

In tal caso, probabilmente starai meglio usando le procedure memorizzate che possono essere modificate sul server e tali modifiche non dovranno essere distribuite.

Sei preoccupato per la sicurezza del tuo database?

In tal caso, probabilmente si desidera utilizzare le stored procedure in modo da non dover concedere l'accesso diretto alle tabelle a un utente.

Se stai scrivendo una piccola applicazione, senza un vasto pubblico, per un sistema che non sarà utilizzato o accessibile al di fuori della tua applicazione, SQL inline potrebbe essere ok.

Answer 7

Con Subsonic utilizzerai inline, viste e procedure memorizzate. Subsonic semplifica l'accesso ai dati, ma non è possibile eseguire alcuna operazione in una query subsonica. Sebbene l'ultima versione, 2.1 stia migliorando.

Per le operazioni CRUD di base, SQL inline sarà semplice. Per esigenze di dati più complesse, sarà necessario creare una vista e quindi verrà eseguita una query subsonica sulla vista.

I processi memorizzati sono utili per calcoli e recupero dei dati più difficili. Il recupero basato su set di solito è sempre più veloce dell'elaborazione procedurale.

L'applicazione Subsonic corrente utilizza tutte e tre le opzioni con ottimi risultati.

Answer 8

Preferisco inline sql a meno che la procedura memorizzata non abbia una logica effettiva (variabili, cursori, ecc.). Ultimamente ho utilizzato LINQ to SQL, prendendo le classi generate e aggiungendo classi parziali con alcune query linq predefinite e comuni. Ritengo che ciò contribuisca a uno sviluppo più rapido.

Modifica: so che mi lascerò a bocca aperta per questo. Se hai mai parlato di chiavi esterne o procedure memorizzate, verrai downmodded. I DBA hanno bisogno di sicurezza del lavoro, immagino ...

Answer 9

I vantaggi della stored procedure (a mio avviso)

1. L'SQL è in un posto
2. Sei in grado di ottenere piani di query.
3. Se necessario, è possibile modificare la struttura del database per migliorare le prestazioni
4. Sono compilati e quindi i piani di query non devono essere costruiti al volo
5. Se si utilizzano le autorizzazioni, si può essere certi delle query che l'applicazione farà.

Answer 10

1. Le procedure memorizzate raggruppano i dati e il codice per manipolare / estrarre tali dati in un punto. Questo rende la vita del tuo DBA molto più semplice (supponendo che la tua app sia abbastanza grande da giustificare un DBA) poiché può ottimizzare in base a fattori noti.

2. Le procedure memorizzate possono contenere la logica che è meglio lasciare nel database. Ho visto procs memorizzati in DB2 / z con molte dozzine di linee, ma tutto ciò che il client deve codificare è una singola riga come "dammi quella lista".

3. il miglior vantaggio dell'utilizzo di processi memorizzati che ho riscontrato è che quando vogliamo cambiare nella logica, in caso di query in linea dobbiamo andare in qualsiasi luogo e cambiarlo e ripetere il roll-up di ogni applicazione ma nella il caso di cambio proc memorizzato è richiesto solo in un punto.

Quindi usa le query incorporate quando hai una logica chiara; altrimenti preferisce i processi memorizzati.