Non si utilizzano le transazioni SQL

2

Sto guardando un codebase in cui uno sviluppatore non usa mai transazioni SQL, cioè ogni aggiornamento / inserimento nel database SQL è un'operazione atomica.

Credo che il codice base trarrebbe beneficio dalle transazioni. Oggi stavo cercando online e in una domanda Stackoverflow un rispondente dice: "In alcune situazioni è meglio avere un aggiornamento parziale piuttosto che nessuno". C'è qualche verità in questo? Suppongo che dipenda in qualche modo dal dominio del problema.

    
posta w0051977 25.04.2013 - 21:01
fonte

2 risposte

8

Dipende non solo dal dominio del problema, ma anche da considerazioni tecniche. Fondamentalmente, si riduce alla semplice domanda: "Ci saranno problemi inaccettabili quando si verifica un aggiornamento parziale?" Alcuni esempi:

  • Trasferimento di denaro da un account a un altro. Un aggiornamento parziale è completamente inaccettabile per ragioni di dominio.
  • Aggiunta di un voto a un sondaggio online e incremento di un conteggio dei risultati (che è solo per la visualizzazione, con il ricalcolo del risultato finale dalla tabella dei voti). Un aggiornamento parziale è probabilmente accettabile.
  • Aggiunta di qualcosa a una relazione n: m. Un aggiornamento parziale comporterebbe uno stato incoerente in cui si dispone di una voce non connessa o di una connessione senza una voce corrispondente. Ciò è inaccettabile per motivi tecnici: si verificherebbe un errore ogni volta che si incontra quella voce e sarebbe probabilmente impossibile correggere questo errore all'interno del sistema.
  • Un'unità hardware che invia batch di dati del sensore da memorizzare. Aggiungere solo alcune delle voci di un batch è probabilmente meglio che perdere tutto questo.

Onestamente, è davvero raro che gli aggiornamenti parziali siano tollerabili.

    
risposta data 25.04.2013 - 21:41
fonte
0

Dal punto di vista del database, i commit frequenti vengono spesso utilizzati per impedire che i record siano illeggibili da altre sessioni mentre vengono bloccati dalla sessione di aggiornamento.

Tuttavia questo varia da RDBMS. Oracle ha sempre avuto un sistema MVCC che impediva ai lettori di impedire a scrittori e scrittori di bloccare i lettori, quindi per esempio non è un problema.

Il troppo frequente impegno su Oracle è strongmente scoraggiato non solo perché può lasciare transazioni parziali nel sistema, ma anche perché un COMMIT richiede un flush buffer del redo sincrono che blocca la sessione (un alto livello di eventi di attesa log_file_sync è sintomatico di over-commettere). I buffer del log di ripetizione vengono svuotati in modo asincrono ogni pochi secondi o quando sono comunque completi di X%, quindi una transazione più lunga può avere meno lavoro da fare durante un commit esplicito se è rimandata comunque fino alla fine della transazione commerciale.

    
risposta data 26.04.2013 - 10:32
fonte

Leggi altre domande sui tag