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.aspxhttp://msdn.microsoft.com/en-au/图书馆/cc853327.aspx

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

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

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

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