Смешивание Guid и Ints в одной базе данных

Question

Вопрос

Есть ли что-то неправильное или опасное в смешивании типов идентификаторов, чтобы гарантировать, что в ближайшем будущем у меня не кончатся ключи, или все типы в моей базе данных должны придерживаться одной и той же стратегии идентификации?

Детали

База данных, которую я создаю, потребует очень большого количества таблиц, а для некоторых из них (в частности, для таблиц соединений) потребуется ожирение записей из-за того, что некоторые элементы представляют собой совокупные корни, которые используются во многих местах со многими ко многим отношениям.

В то время как функциональный аспект работает нормально, я обеспокоен ограничениями столбца identity для определенных вещей. Занимаясь математикой, несложно предвидеть достижение пределов 32-битной идентичности в течение 2 с половиной лет работы. Сначала я подумал о том, чтобы использовать 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 identity вместо int identity. Это может дать вам необходимую передышку, не занимая столько места в ваших ключах. Еще нужно учитывать скорость вставки и то, собираетесь ли вы получать горячие точки в своих индексах. Направляющие будут ближе к случайным, а целые (или большие) будут последовательными.