6

是否可以从 HiLo 切换到 GUID.comb？据我所知，后者结合了 HiLo 的优势，即在客户端管理 Ids，而不是需要调用 DB 来获取新的 Id，优点是 Ids 不可能用完。

目前，我们遇到了 HiLo 生成 Id 如此之大的问题，以至于 Int32（这应该是 Int64，但这更像是我的前任的 WTF）还不够大。我们可以更改为 Int64，但这只是意味着我们会迟到而不是越早遇到问题。

由于 Id 不需要有意义，因此切换到 GUID 似乎是合乎逻辑的。但是，由于我从未尝试过这样的转换，我想知道这里是否有人可以帮助我评估类似的事情可能产生的影响。

4

1 回答 1

6

实际上，切换到 int64 通常就足够了。请记住，您要增加 32 位，这会将 id 空间乘以 +/- 20 亿。你确定这还不够吗？

关于切换到 Guid，它涉及（假设是一个实时数据库）：

  • 创建新的 pk / fk 列
  • 用新值填充 pk 列
  • 根据旧的填充 fk 列
  • 删除当前的外键和主键
  • 删除旧的 pk / fk 列
  • 创建新的主键和外键
  • 更改 id 属性类型和生成器（这是涉及 .net 代码的唯一步骤）

无论如何，虽然 GUID 提供“无限”的 id 并且它很容易生成，但它也有一个缺点是两倍大（128 位）并且稍微难以手动操作（即在调试时您将依赖复制和粘贴

于 2011-02-01T15:05:48.250 回答