какой тип идентификатора записи базы данных использовать: длинный или guid?

Question

В последние годы я использовал базы данных MSSQL, и все уникальные записи в таблицах имеют тип столбца идентификатора bigint (long). Это автоинкремент и, как правило, работает нормально.

В настоящее время я наблюдаю, как люди предпочитают использовать GUID для идентификации записи.

Имеет ли смысл заменить bigint на guid для уникального идентификатора записи?

Я думаю, что это не имеет смысла, так как генерация bigint и сортировка всегда выполняются быстрее, чем guid, но ... возникают некоторые проблемы при использовании двух (или более) отдельных экземпляров приложения и базы данных и их синхронизации Таким образом, вы должны управлять пулами идентификаторов между серверами sql (например: sql1 использует идентификаторы от 100 до 200, sql2 использует идентификаторы от 201 до 300) - это тонкий лед. С идентификатором guid вы не заботитесь о пулах идентификаторов.

Что вы посоветуете для моего зеркального приложения (и базы данных): остаться с традиционными идентификаторами или перейти на GUID?

Заранее спасибо за ваш ответ!

Answer 1

направляющие имеют

Преимущества:

• Возможность создавать их в автономном режиме из базы данных, не беспокоясь о коллизиях.
• Ты никогда не убежишь от них

Недостатки:

• Последовательные вставки могут работать плохо (особенно на кластерных индексах).
  • Последовательные направляющие исправить это
• Занимайте больше места в ряду
• создание одного чисто не дешево
  • но если клиенты генерируют их, это на самом деле не проблема

Столбец по-прежнему должен иметь уникальное ограничение (либо в виде PK, либо в качестве отдельного ограничения, если оно является частью какого-либо другого отношения), поскольку ничто не мешает кому-то предоставить GUID вручную и случайно / намеренно нарушает уникальность.

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

Answer 2

Я использую GUID в любом сценарии, который включает либо репликацию, либо генерацию идентификатора на стороне клиента. В любой из этих ситуаций намного проще управлять идентификацией с помощью GUID.

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

Что касается того, стоит ли использовать автоинкены или переходить на GUID ... одно дело отстаивать GUID в «зеленом» приложении, где вы можете принять все эти решения заранее. Другое - посоветовать кому-нибудь перенести существующую базу данных. Это может быть больше боли, чем стоит.

Answer 3

GUID имеют проблемы с производительностью и параллелизмом, когда происходит разбиение страницы. INT могут запускать заполнение страницы на 100% - добавляются только с одной стороны, GUIDS - везде, поэтому вам, вероятно, придется выполнять более низкое заполнение, которое тратит пространство по всему индексу.

В приложении могут быть выделены GUIDS, чтобы приложение могло знать идентификатор созданной им записи, что может быть удобно; но, технически, возможно генерировать дубликаты GUID (длинные шансы, но, по крайней мере, поставить уникальный индекс для столбцов GUID)

Я согласен на объединение баз данных. Но для меня прямой INT лучше, а потом приходится разбираться, как объединять БД, когда / если это действительно необходимо.

Answer 4

Если ваши данные часто перемещаются, то GUID является лучшим для ключа таблицы. Если вы действительно заботитесь о производительности, просто придерживайтесь int или bigint

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

Answer 5

Если идентификаторы будут отображаться в строке запроса, используйте направляющие, в противном случае используйте long как правило.