Где целесообразно использовать GUID при проектировании баз данных? - PullRequest
Новая
       26

Где целесообразно использовать GUID при проектировании баз данных?

2 голосов
/ 04 марта 2012

Использование GUID в первую очередь основано на необходимости генерировать глобально уникальные идентификаторы.Теоретически, это может быть полезно, когда в нашей базе данных есть таблица (с ее идентификатором), и мы регулярно импортируем записи из внешних систем в эту таблицу.Если и наша локальная база данных, и внешние системы будут использовать GUID для своих идентификаторов, то не должно быть конфликтов дублирования ID.Однако при использовании значений GUID в качестве PK наблюдается снижение производительности.Они больше (16 байт), поэтому индексы PK больше, это может привести к разбиению страницы, поэтому вставка и получение записей занимает больше времени для СУБД, чем использование значений целочисленного типа для идентификаторов PK.GUID в качестве первичного ключа лучше, чем наличие локального внутреннего целочисленного идентификатора, и хранить значения GUID импорта записей в отдельном столбце в моей таблице.Хотелось бы услышать мнения об использовании GUID в реальных примерах, плюсах и минусах :)

1 Ответ

2 голосов
/ 04 марта 2012

Имеется подробное сравнение на ASPFaq

  • Поскольку они гарантированно являются более или менее уникальными, несколько таблиц / баз данных / экземпляров / серверов/ сети / центры обработки данных могут генерировать их независимо, а затем объединять без столкновений;
  • Требуется для некоторых форм репликации;
  • Может генерироваться вне базы данных (например, приложением), поэтому вы можете избежать обхода БД
  • Распределенные значения предотвращают «горячую точку» (если вы не кластеризуете этот столбец, которыйможет привести к аномально высокой фрагментации).

Джефф Этвуд также опубликовал сообщение об этой проблеме здесь

...