I am currently playing with EntityFramework.BulkInsert.
While it really helps with performance of simple inserts (16 seconds with 1.000.000 rows) I can't find any information about inserting objects mapped over multiple tables. The only thing related to that is old (2014) topic from official website stating that it's not possible. Is this still actual?
If so: are there any good workarounds?
EntityFramework.BulkInsert is a very good library which supports simple scenario. However, the library is limited and not anymore supported.
So far, there are only one good workaround and it's using a library which supports everything!
Disclaimer: I'm the owner of the project Entity Framework Extensions
This library supports everything including all associations and inheritance.
By example, for saving multiple entities in different tables, you can use BulkSaveChanges which work exactly like SaveChanges but way faster!
// Easy to use
context.BulkSaveChanges();
// Easy to customize
context.BulkSaveChanges(bulk => bulk.BatchSize = 100);
The library also do more than only inserting. It support all bulk operations:
However unlike EntityFramework.BulkInsert, this library is not free.
EDIT: Answer subquestion
You say way faster - do you have any metrics or a link to metrics
@Mark: You can look on metrics on our website homepage. We report BulkSaveChanges to be at least 15x faster than SaveChanges.
However metric are heavily biased. Too many things may affect it like index, trigger, latency etc!
People usually report us performance improved by 25x, 50x, 80x!
One thing people usually forget when performing benchmarking is calling our library once before the test for JIT compilation! Like Entity Framework, the first hit to the library may take several ms.
If I had a bulk insert problem, I'd not use EF. EF is meant to map objects representing entities during the normal use-cases of your application, where any given transaction should only really touch one entity (assuming your entities are designed around sensible consistency boundaries).
If I was moving lots of data around (imports/exports/transformations etc) then I would use SQL more directly, where I have more control.
