Используя как GUID, так и автоинкрементное целое число
Я изучал использование GUID в качестве первичных ключей в базах данных. До сих пор профессионалы, похоже, перевешивали минусы. Тем не менее, я вижу один момент, когда идентификаторы GUID могут быть не такими, какие я хочу.
В моем приложении пользователи должны иметь возможность идентифицировать объекты на основе удобного идентификатора. Так, например, если они хотят получить конкретный продукт без ввода полного имени, они могут использовать идентификатор продукта. GUID не так легко запомнить для чего-то подобного.
Решение, о котором я думал, это использовать как GUID, так и auto-incrementing integer. GUID будет основным ключом строки, в то время как автоматически увеличивающееся целое число будет индексом, используемым функциями фильтрации приложения. Однако все операторы SQL SELECT, UPDATE, DELETE будут использовать GUID.
- Разница между уникальным и составным первичным ключом В sql-сервере
- первичный ключ и кластеризованный индекс
- Укажите, как генерируются первичные ключи во время импорта XML-данных SSIS
- порядок по первичному ключу
- SQL Server: переименовать первичный ключ
Основной причиной, по которой я хочу использовать GUID, является предотвращение конфликтов при объединении двух баз данных. Если в базе данных № 1 и в базе данных № 2 есть Продукт №2, импортерский скрипт должен будет изменить идентификатор и все внешние ключи, ссылающиеся на него. С идентификаторами GUID мне нужно только изменить идентификатор пользователя в самой таблице, в то время как внешние ключи будут использовать уникальный идентификатор GUID для каждой импортированной записи и поэтому будут работать без изменений.
Итак, мой вопрос: есть ли какие-либо серьезные проблемы (помимо размера поля GUID и легкая фрагментация страниц) с индексом автоматического увеличения индекса и основным ключом GUID?
- Как получить PRIMARY KEY COLUMNS таблицы (в случае первичного ключа COMPOSITE)
- Разница между A не кластеризованным первичным ключом и индексом покрытия с точки зрения производительности
- первичный ключевой тип данных в базе данных SQL Server
- Значение по умолчанию для первичного ключа увеличивает значение на два
- Какой тип данных является Guid на SQL-сервере?
- Вставка строк и обновление строк в таблицах, которые могут иметь или не иметь первичные ключи
- Когда вы будете использовать GUID как первичные ключи?
- Кластерный первичный ключ в столбце идентификатора уникального идентификатора в SQL Server
Я всегда использую суррогатные первичные ключи в своей базе данных. То есть: эти первичные ключи не имеют фактического значения в проблемной области, и поэтому эти первичные ключи никогда не подвергаются воздействию пользователей. (Если этот суррогатный первичный ключ имеет тип GUID или личность, мне все равно, это зависит от требований).
Если вы говорите, что пользователи должны иметь возможность идентифицировать объекты на основе удобного идентификатора, тогда я думаю, что этот удобный для пользователя идентификатор является значением, которое принадлежит вашему «проблемному домену». Это означает, что этот идентификатор действительно должен быть атрибутом в вашей таблице, но он не должен использоваться в качестве первичного ключа в вашей таблице.
Это также позволяет легко изменять значение такого удобного идентификатора (если это необходимо), и вам не придется беспокоиться об изменении связанных внешних ключей.
«Почему« пользователи должны иметь возможность идентифицировать объекты на основе удобного идентификатора »?
На мой взгляд, ваши пользователи должны уведомить записи, используя коды.
Допустим, ваша база данных содержит продукты (как вы упомянули в вопросе). Было бы лучше, если бы у них были коды для представления продуктов, которые пользователи могли бы ввести.
Предположим, у вас есть столы и стулья, как пользователь, я бы предпочел использовать tbl и chr, чем 1 и 2, чтобы определить, о чем я говорю.
В MySQL вам нужно установить свой цифровой ID как PRIMARY KEY , так как AUTO_INCREMENT может быть только PRIMARY KEY , а это значит, что оно также должно быть NOT NULL .
Вы все еще можете определить UNIQUE INDEX в своем столбце GUID и использовать его в любом месте, хотя таблица InnoDB будет группироваться по числовому id , а не по GUID .
Там есть школа мысли, в которой говорится, что вы никогда не должны раскрывать свои суррогатные удостоверения для внешнего мира. Поэтому они сказали бы, что если вам нужен идентификатор бизнеса, вы должны использовать что-то еще для этого.
Эта статья в Википедии , например, говорит следующее:
Disassociation
Значения сгенерированных суррогатных ключей – потому что они генерируются и произвольны – не имеют отношения к реальному значению данных, содержащихся в строке. При проверке другой строки, содержащей ссылку на внешний ключ к суррогатной клавише, невозможно определить смысл ее сохранения этой ссылки, просто просмотрев данные в самой строке. Уровень слоя добавляется к этой косвенности для каждого соединения с внешним ключом, которое нужно перемещаться, пытаясь понять элемент данных. Это также может затруднить проведение аудита, поскольку неверные данные не являются очевидными при проверке.
Суррогатные ключи также не являются естественными для данных, которые экспортируются и совместно используются. Особая трудность состоит в том, что два экземпляра схемы могут содержать записи, которые логически означают одно и то же (то есть – они одинаковы в бизнес-смысле), но которые имеют другой ключ из-за истории того, как были назначены ключи. Подход к решению этого вопроса заключается в том, чтобы принять правило, что суррогатные ключи никогда не экспортируются и не импортируются: они никогда не отображаются за пределами базы данных, кроме как временные данные (наиболее очевидно, при выполнении приложений, имеющих «живое» соединение с базой данных).
Чтобы быть более конкретным в вашем вопросе, да, есть и другие проблемы с использованием GUID в качестве первичных ключей в базах данных:
http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx
Проблема заключается не столько в том, чтобы использовать GUID в качестве первичного ключа, а в том, что он использует несекретный GUID в качестве кластеризованного индекса для таблицы.
Вывод здесь – либо использовать другие поля в качестве кластерного индекса, либо использовать последовательный GUID, чтобы избежать этой фрагментации.