Grandi aggiornamenti del database del volume con un ORM

Question

Mi piace strumenti ORM, ma ho spesso pensato che per aggiornamenti di grandi dimensioni (migliaia di righe), sembra inefficiente per caricare, aggiornare e salvare quando qualcosa di simile

UPDATE [table] set [column] = [value] WHERE [predicate] 

sarebbe dare prestazioni molto migliori.

Tuttavia, supponendo che si volesse percorrere questa rotta per motivi di prestazioni, come si sarebbe quindi assicurarsi che tutti gli oggetti memorizzati nella cache fossero aggiornati correttamente.

Supponiamo che tu stia utilizzando LINQ to SQL e hai lavorato su un DataContext, come assicurarti che l'UPDATE ad alte prestazioni si rifletta nel grafico dell'oggetto DataContext?

Questo potrebbe essere un "non si" o "utilizzare i trigger sul DB per chiamare il codice .NET che elimina la cache" ecc. Ecc., Ma sono interessato a conoscere soluzioni comuni a questo tipo di problema.

Answer 1

Hai ragione, in questo caso utilizzando un ORM per caricare, modificare e quindi i record di persistenza non è efficiente. Il mio processo più o meno così

1) l'uso implementazione All'inizio ORM, nel mio caso NHibernate, esclusivamente

2) Dato che lo sviluppo matura identificare i problemi di prestazioni, che includerà aggiornamenti di grandi dimensioni

3) refactoring quelli fuori a SQL o SP approccio

4) comando Usa Refresh (oggetto) per aggiornare gli oggetti memorizzati nella cache,

mio grosso problema è stato informare altri clienti che l'aggiornamento si è verificato. Nella maggior parte dei casi, abbiamo accettato che alcuni client siano obsoleti, come nel caso dell'uso standard di ORM, e quindi controlliamo un timestamp su update/insert.

Answer 2

Gli ORM sono ideali per lo sviluppo rapido, ma hai ragione: non sono efficienti. Sono fantastici in quanto non è necessario pensare ai meccanismi sottostanti che convertono gli oggetti in memoria in righe nelle tabelle e viceversa. Tuttavia, molte volte l'ORM non sceglie il processo più efficiente per farlo. Se ti interessa davvero le prestazioni della tua app, è meglio lavorare con un DBA per aiutarti a progettare il database e ad accordare le tue query in modo appropriato. (o almeno capire i concetti di base di SQL te stesso)

Answer 3

Gli ORM non saranno efficienti quanto l'SQL realizzato a mano. Periodo. Proprio come l'assemblatore fatto a mano sarà più veloce di C#. Indipendentemente dal fatto che la differenza di prestazioni sia importante dipende da molte cose. In alcuni casi, il livello più alto di ORM di astrazione ti dà forse più valore di una prestazione più elevata, in altri casi no.

Le relazioni di movimento con il codice oggetto possono essere molto belle ma, come giustamente sottolinea, ci sono potenziali problemi.

Detto questo, personalmente ritengo che ORms sia in gran parte una falsa economia. Non mi ripeterò qui ma indicherò semplicemente Using an ORM or plain SQL?

Answer 4

La maggior parte degli ORM dispone anche di funzionalità per eseguire in modo efficiente aggiornamenti di grandi dimensioni o "in blocco". La Sessione senza stato è un meccanismo di questo tipo disponibile in Hibernate per Java che apparentemente sarà disponibile in NHibernate 2.x:

http://ayende.com/Blog/archive/2007/11/13/What-is-going-on-with-NHibernate-2.0.aspx

Answer 5

aggiornamenti di massa sono un disegno discutibile. A volte sembrano necessari; in molti casi, tuttavia, una migliore progettazione dell'applicazione può eliminare la necessità di aggiornamenti di massa.

Spesso, un'altra parte dell'applicazione ha già toccato ogni oggetto uno alla volta; l'aggiornamento "bulk" avrebbe dovuto essere eseguito nell'altra parte dell'applicazione.

In altri casi, l'aggiornamento prelude all'elaborazione altrove. In questo caso, l'aggiornamento dovrebbe far parte dell'elaborazione successiva.

La mia strategia di progettazione generale consiste nel rifattorizzare le applicazioni per eliminare gli aggiornamenti di massa.