我们正在使用Entity Framework 5 Code First方法将MS-Access数据库迁移到SQL Server Compact 4.0。我们发现使用数据库生成的整数ID非常慢并且使其变得更糟，延迟随着数据库的大小呈指数增长。这使得使用Identity列不可能，并且似乎在与实体框架配对的SQL Server Compact 4.0中实现了此功能。
因此，我们进行了一些测试，发现使用客户端生成的密钥将插入速度提高了至少20倍，插入的指数增长消失了。
现在我们正在研究生成客户端ID的最佳方法。使用GUID似乎是最安全的选项，但我读到这会对读取操作产生负面影响。是否存在使用客户端生成的自动递增整数的策略？
编辑： 我将研究导致这个问题的潜在问题。同时，我的真实问题可以回答吗？ ： - ）
EDIT2： 令人恼火的是，似乎没有人相信使用自动id与EF和SQL Server compact 4.0的说法是如此之慢。我发布了a separate question关于这一点的概念证明，应该很容易重现。
答案 0 :(得分：1)
如果您使用EF移动大量数据，那么您做错了。使用ADO.NET，例如使用BULK COPY方法（使用SQL CE使用SqlCeUpdateableRecord）。您可以使用我的SqlCeBulkCopy库来节省一些编码工作。
答案 1 :(得分：1)
我不认为身份生成的方式是性能问题的根源
我想如果你想在迁移过程中获得更好的性能，
在转换过程之前，您可以禁用主键和外键等约束
在你的主桌上。 （这可以通过编写脚本或手工制作）
但是，数据完整性将是您的新问题，转换代码必须很强，因此在转换过程之后，可以启用约束。
希望这会有所帮助。
答案 2 :(得分：0)
我看到的解决方案。
a）尝试修复性能问题。我的建议（不要在上下文中使用大量实体。）尝试尽可能少的业务问题。不要使用合并跟踪等...请参阅EF性能提示。 http://blogs.msdn.com/b/wriju/archive/2011/03/15/ado-net-entity-framework-performance-tips.aspx 和http://msdn.microsoft.com/en-au/library/cc853327.aspx
b）使用Guid。外部分配（不是顺序但快速）
c）使用在内存中运行的客户Integer生成器，可以一次分配多个密钥，并且可以保持当前状态。 SAP使用此技术。他们称之为“数字范围”。 可以非常快，但不如b）快。
btw我使用GUID而不是数据库生成的ID来进行部分数据库复制和迁移轻松/简单。 ： - ）