Eugene Philipov ha eseguito un benchmark su più INSERT s in una query e ha scoperto che sono molto più veloci di molti inserti sequenziali uno dopo l'altro. Questo in realtà non è stato una sorpresa perché INSERT è un'operazione molto semplice.
Per gli aggiornamenti il motivo per cui dovresti effettuare più viaggi su un database è perché il codice è semplicemente più facile da capire dal programmatore. A meno che non sia ritenuto necessario, il calo delle prestazioni non sarà più sostanziale.
La situazione degli aggiornamenti che si comportano diversamente dagli inserimenti è causata dalla clausola CASE/WHEN che deve essere presente quando si desidera aggiornare gli attributi di più righe con valori diversi. Per questo motivo, il database non solo esegue la ricerca e l'aggiornamento, ma deve anche decidere quale valore dovrebbe essere effettivamente utilizzato come sostituto di quello corrente.
Come programmatore hai sempre la possibilità di scrivere un metodo che aggiornerebbe un attributo di più righe con lo stesso valore. A livello di database questo è molto semplice da fare, si fornisce un constrait su quali righe dovrebbero essere influenzate (molto probabilmente usando la clausola IN ), quindi si fornisce la sostituzione ed è fatto. Non è necessario decidere a livello di database come mai, basta una semplice procedura di ricerca e sostituzione.
Ho detto che l'aggiornamento di più righe con valori diversi non è altrettanto performante di più INSERT , ma comunque sarà leggermente più veloce rispetto a fare più viaggi nel database, perché ciò costa risorse (principalmente tempo - per connettersi al database e per eseguire ogni query). Ma a meno che tu non stia parlando di milioni di file per l'aggiornamento alla rinfusa, non penso che tu debba preoccuparti.
Hai menzionato Martin Fowler nel suo esempio prende in particolare più viaggi nel database. Nel libro mostra un esempio dell'azione di inserimento, in cui ogni record viene elaborato individualmente. Anche così, lo stesso Martin Fowler dice quanto segue:
To avoid multiple database calls, you can leave all your updates to
the end. To do this you need to keep track of all the objects that
have changed. You can use variables in your code for this, but they
soon become unmanageable once you have more than a few. Variables
often work fine with a Transaction Script (110), but they can be very
difficult with a Domain Model (116).
Rather than keep objects in variables you can give each object a dirty
flag that you set when the object changes. Then you need to find all
the dirty objects at the end of your transaction and write them out.
Source: Martin Fowler, P of EAA
La parte importante della citazione è: tu puoi lasciare tutti gli aggiornamenti alla fine . Nota come non dice che devi farlo, perché nella maggior parte dei casi non è semplicemente necessario. Dalla mia esperienza, l'operazione di massa (operazione che significa INSERT , UPDATE e / o DELETE ) hack non risolverà completamente il tuo problema di prestazioni. Se ne hai uno, è più probabile che lo aggiusti migliorando la tua architettura, introducendo il caching, magari usando tecnologie diverse e altro.
Penso che quello che ti interessa è l'ottimizzazione prematura . Sì, è incredibile avere una visione di un sistema che è veloce, ma è ancora meglio avere un sistema, quindi puoi effettivamente usarlo.
Quindi, mentre Mr. Fowler non fornisce un esempio reale di aggiornamenti di massa, è completamente possibile se / quando necessario. Molto probabilmente ha scelto di non mostrare un esempio di ciò, perché il normale approccio sequenziale di solito funziona. Questa è la mia ipotesi. La sua ragione di non averlo inserito nel libro potrebbe essere diversa, ma per questo è necessario chiederglielo direttamente.