问题
We are migrating our MS-Access database to SQL Server Compact 4.0 using the Entity Framework 5 Code First approach. We found that using Database generated Integer ID's is very slow and to make it worse, the delay increases exponentially with the size of the database. This makes using an Identity column impossible and it seems there is a bad implementation of this feature in SQL Server Compact 4.0 paired with the Entity Framework.
So, we ran some tests and found that using a client side generated key speeds op insertion by at least 20 times, the exponential increase in insertion disappears.
Now we are looking at a the best way to generate client side ID's. Using GUID's seems the most secure option, but I read that this negatively impacts read actions. Is there a strategy in using auto-incremented Integers that are client side generated?
EDIT: I will investigate the underlying problem that lead to the question further. In the mean time can my real question be answered please? :-)
EDIT2: It is pretty exasperating that nobody seems to believe the assertion that using auto-id's with EF and SQL Server compact 4.0 is so slow. I posted a separate question about this with a proof of concept that should be easily reproducible.
回答1:
If you are moving large amounts of data with EF, you are doing it wrong. Use ADO.NET, and for example a BULK COPY approach instead (with SQL CE use SqlCeUpdateableRecord). You could use my SqlCeBulkCopy library to save some coding effort.
回答2:
I dont think the way of identity generation is the source of performance problem.
I think if you want to get a better performance during migration process,
before conversion process, you can disable Primary keys and foreign keys and other constraint
on your main tables. (this could be done by scripting or manualy)
However data integrity will be your new concern and you conversion code must be strong so after conversion process, enabling the constraints could be done.
hope this helps.
回答3:
Solution as I see it.
a)Try Fix Performance problem. My suggestions (dont use large numbers of entities inside context.) try as few as the business problem will allow. Dont use merge tracking etc... See EF performance tips. http://blogs.msdn.com/b/wriju/archive/2011/03/15/ado-net-entity-framework-performance-tips.aspx and http://msdn.microsoft.com/en-au/library/cc853327.aspx
b)Use a Guid. Allocate externally (its not sequential, but fast)
c)Use a customer Integer generator, that runs in memory, can allocate many keys at once and can persist the current state. This technique is used by SAP. They call it "number range". Can be very fast but not as fast as b).
btw I use GUIDs and not DB generated IDs to make partial DB copies and migrations Easy/easier. :-)
来源：https://stackoverflow.com/questions/14740710/is-using-a-sequential-guid-the-only-viable-alternative-to-a-database-generated