Dov'è il posto migliore per gestire le transazioni nella stored procedure o nell'applicazione?

Question

Quando la mia applicazione C# .net aggiorna i record in più di una tabella, utilizzo le transazioni, quindi se qualcosa dovesse fallire durante la transazione posso eseguire il rollback.

Quale è una pratica migliore?

-Utilizzare la stored procedure con BEGIN TRANSACTION/ROLLBACK/COMMIT TRANSACTION; -Usa TransactionScope nell'applicazione come di seguito:

 

    using (TransactionScope ts = new TransactionScope()) 
    { 
    } 
 

Answer 1

Questo non è un problema di logica aziendale, è un problema di integrità dei dati e ritengo che sia giusto fare nella stored procedure. Mi piace mantenere la logica delle transazioni il più vicino possibile alle operazioni per accorciarne la durata.

Answer 2

TransactionScope è un modo davvero piacevole per gestire le transazioni in codice. Consente di annidare il codice transatto su più metodi e ridimensionare automaticamente in modalità distribuita, se necessario.

Preferisco utilizzare TransactionScope su transazioni proc memorizzate, perché offre un controllo molto maggiore nel codice.

Answer 3

Oppure puoi farlo in entrambi. Controllare il collegamento: http://www.4guysfromrolla.com/webtech/080305-1.shtml

Answer 4

Se la transazione sta per un database, allora è meglio fare la transazione nella stored procedure. L'altro modo può essere causato solo da un problema logistico (DBA non ti piace o è in vacanza). Se chiamate una fonte transazionale diversa (SQL Server e Oracle) in una transazione, allora non c'è altra scelta che fare la transazione nel codice.

Answer 5

Consiglio vivamente di impostare una procedura per una pagina e gestire tutte le azioni sql presenti. Se nella pagina sono presenti più attività da eseguire che richiedono più procedure, è sufficiente disporre di una procedura per gestire le altre procedure. La tua procedura può sempre restituire più recordset se necessario.

• pagina potrete eseguire più velocemente - non un sacco di dati che vanno avanti e indietro, un solo tiro. Tutto il codice su sql è già compilato con piani di esecuzioni.
• Sarete in grado di gestire i vostri errori molto di più efficiente - in un unico luogo in contrapposizione ai due posti - avere due sistemi separati per decidere se è abbastanza cirtical a fallire - passando eventuali errori avanti e indietro per mantenere l'integrità dei dati.
• Si riducono al minimo i punti di errore. Se la transazione sta andando bene, ma il server web singhiozzo, il server sql rimane in attesa di una risposta .
• È possibile risparmiare tempo e risolvere i problemi.
• Aiuterà a modulare il codice sul server sql. È possibile riutilizzare sprocs per eseguire attività simili e finire con un sistema robusto scalabile più flessibile. HTH

Answer 6

Qui ci sono i miei 2 semplici regole per quando utilizzare le transazioni:

• se la procedura ha più di una dichiarazione di dati cambia, conterrà una transazione.
• se l'applicazione chiama più di una stored procedure che modifica i dati, conterrà una transazione.