Il mio reparto sviluppa software per migrare database per i nostri clienti dal loro vecchio software CRM al nostro. In questo processo potremmo inserire milioni di righe, elaborate una alla volta, poiché dobbiamo eseguire mappature e formattazioni per passare dal loro vecchio sistema (che potrebbe essere qualsiasi cosa, da un database relazionale a un set di file binari) a il nostro database MS-SQL.
Attualmente utilizziamo un modello consumer del produttore che si legge dal vecchio sistema al nostro mapper, quindi usiamo un altro modello produttore / consumatore per passare da questo in thread DataTable locali che vengono visualizzati in sequenza ogni 15.000 righe in un SQLBulkCopy operazione per mantenere basso il numero di oggetti contenuti nella ram (tabelle più grandi possono essere facilmente scaricate il limite di 2 GB per un'applicazione a 32 bit se proviamo a tenere l'intera tabella in memoria prima di inserirla.)
Il problema è che questa è una specie di installazione di kludge per essere in grado di generare le nuove righe e inserirle nel database. Recentemente abbiamo avuto l'opportunità di riscrivere il database per soddisfare le nostre esigenze e ho lavorato al mio manager all'idea di utilizzare qualche forma di ORM.
Ho iniziato a dare un'occhiata a varie soluzioni ORM, e so che vogliamo stare con un puro stack Microsoft (è stato abbastanza difficile convincere il mio manager a considerare l'utilizzo di un ORM, e non ho palle di neve possibilità di convincerlo a utilizzare una libreria di terze parti, poiché l'app CRM principale utilizza una libreria di elaborazione di immagini di terze parti che non è molto buona e da allora ha odiato le librerie di terze parti). Confrontando Linq-to-Sql e ADO.net Entity Framework penso che EF soddisfi meglio le nostre esigenze. Tuttavia sono preoccupato per le prestazioni.
La maggior parte delle app CRUD sono Read- > Aggiorna a velocità ridotta (visualizza solo un record o un set di record con una variabile comune alla volta). Tuttavia ci limiteremo a creare, creare, creare. Un ORM come EF è progettato per farlo?
Il mio manager è ossessionato dalle prestazioni. Quando questo processo è stato eseguito in VB6 (come è stato fatto fino a due anni fa) potrebbero essere necessarie diverse ore per eseguire una conversione. Con il nostro attuale kludge i più lunghi impiegano al massimo mezz'ora per elaborare diversi Gigs of records (la parte più lenta si occupa di quella libreria di immagini di terze parti che ho menzionato prima, quelli che sono testo puro impiegano al massimo 10 minuti). Potrei potenzialmente vedere un rallentamento nell'EF rispetto all'utilizzo di SqlBulkCopy e cosa posso fare per mitigare il costo corrente se lo fa?