2

我们正在使用 Entity Framework 5 Code First 方法将我们的 MS-Access 数据库迁移到 SQL Server Compact 4.0。我们发现使用数据库生成的整数 ID 非常慢，更糟糕的是，延迟随着数据库的大小呈指数增长。这使得无法使用 Identity 列，并且在与实体框架配对的 SQL Server Compact 4.0 中，此功能的实现似乎很糟糕。

因此，我们进行了一些测试，发现使用客户端生成的密钥将操作插入速度提高了至少 20 倍，插入的指数增长消失了。

现在我们正在寻找一种生成客户端 ID 的最佳方式。使用 GUID 似乎是最安全的选择，但我读到这会对读取操作产生负面影响。是否有使用客户端生成的自动递增整数的策略？

编辑：我将进一步调查导致该问题的潜在问题。同时，我的真正问题可以回答吗？:-)

EDIT2：令人非常恼火的是，似乎没有人相信在 EF 和 SQL Server compact 4.0 中使用 auto-id 如此缓慢的断言。我发布了一个单独的问题，其中包含一个应该很容易重现的概念证明。

4

3 回答 3

1

我不认为身份生成的方式是性能问题的根源。
我认为如果您想在迁移过程中获得更好的性能，在转换过程之前，您可以禁用主表上的主键和外键等约束。（这可以通过脚本或手动完成）
但是数据完整性将是您的新关注点，并且您的转换代码必须强大，因此在转换过程之后，可以完成启用约束。
希望这可以帮助。

于 2013-02-10T19:20:50.137 回答
1

如果您使用 EF 移动大量数据，那么您做错了。使用 ADO.NET，例如使用 BULK COPY 方法（对于 SQL CE，使用 SqlCeUpdateableRecord）。您可以使用我的 SqlCeBulkCopy 库来节省一些编码工作。

于 2013-02-07T07:36:15.367 回答
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/图书馆/cc853327.aspx

b) 使用指南。外部分配（它不是顺序的，但速度很快）

c) 使用在内存中运行的客户整数生成器，可以一次分配许多键并且可以保持当前状态。SAP 使用此技术。他们称之为“数字范围”。可以非常快，但不如 b) 快。

顺便说一句，我使用 GUID 而不是数据库生成的 ID 来制作部分数据库副本和迁移更容易/更容易。:-)

于 2013-02-11T15:06:20.627 回答