Использование GUID и автоинкрементного целого числа

Question

Я изучал использование идентификаторов GUID в качестве первичных ключей в базах данных. Пока что плюсы перевешивают минусы. Однако я вижу один момент, когда GUID может быть не тем, что я хочу.

В моем приложении пользователи должны иметь возможность идентифицировать объекты на основе удобного идентификатора. Так, например, если они хотят получить конкретный продукт без ввода полного имени, они могут использовать идентификатор продукта. GUID не так легко запомнить для чего-то подобного.

Решением, о котором я думал, является использование как GUID, так и целого числа с автоинкрементом. GUID был бы первичным ключом строки, в то время как автоматически увеличивающееся целое число было бы индексом, используемым функциями фильтрации приложения. Однако все операторы SQL SELECT, UPDATE, DELETE будут использовать GUID.

Основная причина, по которой я хочу использовать GUID, заключается в предотвращении конфликтов при объединении двух баз данных. Если база данных № 1 и база данных № 2 имеют продукт № 2, сценарию импортера придется изменить идентификатор и все внешние ключи, ссылающиеся на него. С GUID мне нужно всего лишь изменить удобный для пользователя идентификатор в самой таблице, в то время как внешние ключи будут использовать GUID, уникальный для каждой импортированной записи, и поэтому будут работать без изменений.

Итак, мой вопрос: есть ли серьезные проблемы (помимо размера поля GUID и легкой фрагментации страницы) с наличием целочисленного индекса с автоинкрементом и первичного ключа GUID?

Answer 1

Я всегда склонен использовать суррогатные первичные ключи в моей базе данных. То есть: эти первичные ключи не имеют реального значения в проблемной области, и, таким образом, эти первичные ключи никогда не становятся доступными для пользователей. (Если этот суррогатный первичный ключ имеет тип GUID или идентичность, мне все равно; это зависит от требований).

Если вы говорите, что пользователи должны иметь возможность идентифицировать объекты на основе удобного для пользователя идентификатора, то я думаю, что этот удобный для пользователя идентификатор является значением, которое принадлежит вашему «проблемному домену». Это означает, что этот идентификатор действительно должен быть атрибутом в вашей таблице, но его не следует использовать в качестве первичного ключа в вашей таблице.

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

Answer 2

«Почему« пользователи должны иметь возможность идентифицировать объекты на основе удобного для пользователя идентификатора »?

По моему мнению, ваши пользователи должны itentify записи с использованием кодов.

Допустим, ваша база данных содержит продукты (как вы упомянули об этом в Вопросе). Разве не было бы лучше, если бы у них были коды для представления продуктов, которые могли бы вводить пользователи.

Допустим, у вас есть столы и стулья, как пользователь, я бы предпочел использовать tbl и chr, чем 1 и 2, чтобы определить, о чем я говорю.

Answer 3

Если говорить более конкретно о вашем вопросе, то есть и другие проблемы с использованием идентификаторов GUID в качестве первичных ключей в базах данных:

http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx

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

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

Answer 4

Существует школа мысли, которая говорит, что вы никогда не должны раскрывать свои суррогатные удостоверения личности для внешнего мира. Поэтому они скажут, что если вы хотите получить бизнес-идентификатор, вы должны использовать для него что-то другое.

Эта статья в Википедии , например, гласит:

Disassociation

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

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

Answer 5

В MySQL вам необходимо установить числовое значение ID как PRIMARY KEY, поскольку AUTO_INCREMENT может быть только PRIMARY KEY, что означает, что оно также должно быть NOT NULL.

Вы все еще можете определить UNIQUE INDEX в столбце GUID и использовать его где угодно, хотя таблица InnoDB будет сгруппирована по числовому id, а не по GUID.