Dove dovrebbero essere attive le query del database?

Question

Le query dovrebbero risiedere all'interno delle classi che richiedono i dati? Le query dovrebbero vivere in stored procedure nel database in modo che siano riutilizzabili?

Nella prima situazione, la modifica delle query non influirà su altre persone (altro codice o persone che generano report, ecc.). Nel secondo, le query sono riutilizzabili da molti e esistono solo in un posto, ma se qualcuno le rompe, sono infrante per tutti.

Answer 1

Ero abituato alla soluzione di archiviazione memorizzata, ma ho modificato la mia musica nell'ultimo anno, poiché i database sono diventati più veloci e gli ORM sono entrati nello stream principale. C'è sicuramente un posto per i proc memorizzati. Ma quando si tratta di semplice CRUD sql: un inserto di linea/aggiornamento/selezione/cancellazione, usare un ORM per gestire questa è la soluzione più elegante a mio parere, ma sono sicuro che molti sosterranno l'altro modo. Un ORM farà in modo che la connessione SQL e DB si estinguano dal codice e rendano la logica di persistenza molto più fluida con la tua app.

Answer 2

Suggerisco di inserirli come stored procedure nel database. Non solo avrai il vantaggio del riutilizzo, ma assicurerai anche che la stessa query (essendo una selezione, aggiornamento, inserimento, ecc.) Sia la stessa perché stai utilizzando la stessa stored procedure. Se devi cambiarlo, lo cambierai solo in un posto. Inoltre, potrai sfruttare la potenza di elaborazione del server di database invece del server/computer in cui risiede la tua applicazione. Questo è il mio suggerimento.

Buona fortuna!

Answer 3

Dipende/è situazionale. Ci sono argomenti molto forti a favore e contro entrambe le opzioni. Personalmente, non mi piace davvero vedere la logica aziendale divisa tra il database (nelle stored procedure) e nel codice, quindi di solito voglio tutte le query nel codice nella massima misura possibile.

Nel mondo Microsoft, ci sono cose come Reporting Services che possono recuperare dati da classi/oggetti anziché (e in aggiunta a) un database/stored procedure. Inoltre, ci sono cose come Linq che ti danno query più fortemente digitate nel codice. Esistono anche ORM forti e maturi come NHibernate che consentono di scrivere praticamente tutti i tipi di query dal codice.

Detto questo, ci sono ancora momenti in cui si eseguono tipi di set di righe con le query che funzionano molto meglio in una stored procedure rispetto al codice.

Nella maggior parte delle situazioni, entrambe le opzioni funzionano correttamente.

Answer 4

Dal mio punto di vista, penso che i proc memorizzati siano la strada da percorrere. In primo luogo, sono più facili da gestire poiché un rapido cambiamento in uno significa semplicemente eseguire lo script senza ricompilare l'applicazione. In secondo luogo sono molto meglio per la sicurezza. È possibile impostare le autorizzazioni a livello sp e non direttamente sulle tabelle e viste. Questo aiuta a prevenire le frodi perché gli utenti non possono fare nulla direttamente sul data base che non è specificato in un proc memorizzato. Sono più facili da sintonizzare sulle prestazioni. Quando si utilizzano stored proc, è possibile utilizzare i metadati delle dipendenze del database per aiutare a determinare l'effetto delle modifiche del database sulla base di codice. In molti sistemi, non tutte le operazioni di accesso ai dati o anche le operazioni CRUD avverranno tramite l'applicazione, poiché il codice mi sembra controproducente. Se tutto l'accesso ai dati è in un posto (un'idea che supporto), dovrebbe essere nel database dove è accessibile a tutte le applicazioni o processi che potrebbero aver bisogno di usarlo.

Ho trovato che i programmatori di applicazioni spesso non considerano il modo migliore per un database di elaborare le informazioni poiché sono focalizzate sull'applicazione non sul back-end. Inserendo il codice per il database nel database a cui appartiene, è più probabile che venga visto e rivisto da specialisti di database che considerano il database e la sua perfomance.Supportiamo centinaia di database e applicazioni qui. Posso cercare in qualsiasi database e trovare il codice che ho bisogno di trovare quando qualcosa è lento. Non devo caricare il codice dell'applicazione per ognuna delle centinaia di applicazioni diverse solo per vedere la parte di cui ho bisogno per svolgere il mio lavoro.