将Guid和Ints混合在一个数据库中

Question

问题

  

为了确保我不会在不久的将来用完密钥，或者我的数据库中的所有类型是否都遵循相同的身份策略，是否存在混合身份类型的任何内在错误或危险？

详细

我正在构建的数据库需要大量的表，其中一些（特别是联结表）将需要肥胖数量的条目，因为某些元素是聚合根在许多地方使用，具有多对多关系。

虽然功能方面工作正常，但我担心某些事情的身份列的限制。做数学运算，不难预见在运行2年半后达到32位身份的极限。我最初的想法是使用 Guid 来表示那些特定的表而不是32位的整数，但是我对将两者混合在一起感到恐惧。我听说过有关这种做法的一些非常糟糕的事情。

我正在使用nHibernate / Fluent nHibernate来设计我的数据库映射。但是，例如，我有以下结构...

class Member : IIdentity<int>
{
 public virtual int Id { get; set; }
}

class Page : IIdentity<Guid>
{
 public virtual Guid Id { get; set; }
 // multiple other properties
}

不少于8个对象具有IList<Page>，并且Page可以在多个对象之间重复使用（因此，它是多对多关系）。所以它是使用HasManyToMany在我的映射中定义的。同样的原则延伸到其他几个对象。

Answer 1

GUID的优点在于，无论记录来自哪个数据库，它们都是唯一的。如果您正在访问多个数据库或者需要识别除模式之外的唯一对象，那么您应该使用GUIDS。

否则最好使用32位整数。您的应用程序听起来很耗费资源，您需要考虑整数比GUIDS表现更好。

Answer 2

您可以使用bigint标识而不是int标识。这可能会为您提供所需的喘息空间，而无需在钥匙上占用太多空间。还需要考虑的是插入率以及是否要在索引中获取热点。 Guids将更接近随机，而整数（或bigints）将是连续的。