È una domanda molto comune ma importante per me poiché nel mio progetto ho iniziato a convertire una query codificata in una procedura memorizzata, e conosco il vantaggio che ne deriva. Tuttavia, esiste uno scenario specifico in cui evitare di utilizzare Stored Procedure?Quando ci sono vantaggi nell'usare la stored procedure su una query hard coded?
C'è un blog normale post che invio a chiunque pensi che le stored procedure abbiano sempre senso tranne che in rare condizioni. Generalmente cita un errore lungo la linea che è necessario fare una legge contro l'uccisione di persone per fermare gli assassini.
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
Il link sopra elenca un sacco di veramente buoni argomenti su quando, e quando non, di utilizzare le stored procedure. Tra questi ci sono quelli, specialmente in C#, che fondamentalmente ignorano tutto ciò che il framework ti dà, in termini di potere di avere decisioni UI sensate per le domande, in favore di ... un incubo di manutenzione.
Post un po 'obsoleto, date le modifiche nei disegni di database e nel codice compilato, ecc. – Lloyd
Difficilmente. Non ci sono modifiche al codice compilato nei principali database da allora, e nessuno dei due database progetta neanche. – TomTom
@TomTom Che era SQL Server di 12 anni fa, ci sono stati grandi cambiamenti nel 2008 R2 dal 2000, per non parlare dell'imminente versione 2012. – mattytommo
In genere è sempre meglio utilizzare le stored procedure. Quando li si utilizza, il vantaggio principale è che se si esegue la query più volte, con la stored procedure manterrà il piano di esecuzione per il riutilizzo.
Ci sono molti vantaggi di utilizzare loro, vedi qui per riferimento: http://blog.sqlauthority.com/2007/04/13/sql-server-stored-procedures-advantages-and-best-advantage/
Edit: Mentre l'articolo è a partire dal 2007, i principi fondamentali sono in gran parte la stessa
La parola chiave in questa risposta è "generalmente", non posso essere d'accordo sul fatto che generalmente è sempre meglio usare le stored procedure, posso essere d'accordo sul fatto che in genere è preferibile usarle ... Potrebbe sembrare che io sia un pedante qui ma Non sono. +1 per il link del grande articolo. –
Questa domanda viene posta molto e here è un buon post sull'argomento.
Tuttavia, personalmente direi che evitare la logica complessa nelle stored procedure è difficile da mantenere in un secondo momento e non è il posto migliore per metterlo. I mapper ORM sono ora utilizzati in modo estensivo e alcuni di quelli più grandi (Hibernate/NHIbernate, EF ecc.) Generano query optomised e hanno eccellenti strategie di caching.
Evitare anche un sistema con molti molti molti stored proc (ho visto un sistema con oltre 4k stored proc e fidati di me non vuoi andare lì).
Modifica
avrei ampliato la mia risposta e lo farà ora, stored procedure però hanno un grande uso perché sono eseguite sul server stesso che sono grandi in cui grandi quantità di dati devono essere elaborati e non riacquistati su una connessione di rete e potresti avere bisogno di diversi round trip nel database per ottenere lo stesso risultato, quindi tendo a optomise in stored procedure, la maggior parte delle ORMS può eseguire uno sproc e riportare i risultati mappati e quindi questo aggiunge alla ricchezza della soluzione orm.
Tuttavia, se si trova che tutto ciò che si sta facendo è eseguire sproc in modo esclusivo tramite ORM, non si ha realmente bisogno dell'orm. Quindi in questi giorni è una optomizzazione delle prestazioni. Dove sono interessati grandi set di dati. Inoltre, tende ad essere un sacco di opinioni errate/abitudini da parte di sviluppatori e DBA simili che possono portare a uno stato di guerra, in cui alle persone viene detto "tutto il codice deve essere in sproc" o "tutto il codice deve essere generato da orm ", questo è uno stupido stato di cose.
L'altra cosa che vorrei sottolineare è che ho visto sproc con tutti i tipi di bug in loro e dai nostri sviluppatori di software di natura non sono in genere le persone migliori per scrivere sql in quanto non tendiamo a pensare in un modo "set-like". Questo per non dire che gli sviluppatori non possono scrivere un ottimo codice SQL proprio non è la nostra specializzazione.
Quante volte hai visto uno sproc che scende un percorso di codice una volta .. ottiene il suo piano memorizzato nella cache e quindi non è ottimale come risultato perché ogni volta successiva non scende lungo quel percorso ... Ho visto molto.
Sono lenti. NHibernate asetc. - A seconda del tuo modo di fare e di quello che è il tuo lobgic, BlToolkit/Linq2DB può essere MOLTO più veloce. – TomTom
Linq2Sql! = Linq2DB –
La procedura consigliata consiste nell'utilizzare le stored procedure.
Grazie al cielo, i te4am SANE licenziano le persone che pensano che le 4 migliori pratiche abbiano rilevanza. – TomTom
Siamo spiacenti ma questo pensiero è obsoleto. –
quello che si sta confrontando con stored procedure> qualsiasi altra alternativa> –
a confronto con interrogazione codificato duro (SQL) in codice dietro di stored procedure. –