Переход от целых к GUID в качестве первичных ключей

Question

Я использую несколько ссылочных таблиц с целочисленными первичными ключами. Теперь я хочу изменить int на GUID, оставив все ссылки без изменений. Какой самый простой способ сделать это?

Спасибо!

Добавление

Я понимаю этот процесс в целом, поэтому мне нужны более подробные советы, например, как заполнить новый столбец GUID. Использование значения по умолчанию newid () является правильным, но что за уже существующие строки?

Answer 1

• Создать новый столбец для guid значение в основной таблице. Использовать тип данных uniqueidentifier, сделайте это не нуль с newid () по умолчанию, так все существующие строки будут заполнены.
• Создание новых столбцов уникальных идентификаторов в дочерних таблицах.
• Выполните операторы обновления, чтобы построить отношения гильдии, используя существующие отношения int для ссылки на сущности.
• Удалите исходные столбцы int.

Кроме того, оставьте немного места на страницах данных / индекса (укажите fillfactor <100), поскольку направляющие не последовательны, как столбцы int identity. Это означает, что вставки могут находиться в любом месте диапазона данных и вызовут разбиение страниц, если ваши страницы заполнены на 100%. </p>

Answer 2

Во-первых: Боже мой, почему?!?!?

Во-вторых, вам нужно сначала добавить столбец GUID ко всем таблицам, а затем заполнить их на основе значения int. После этого вы можете установить GUID на первичные / внешние ключи, а затем удалить столбцы int.

Чтобы обновить значение, вы должны сделать что-то вроде

1. Установить новые GUID в таблице первичных ключей
2. Запустите это:

.

UPDATE foreignTable f
SET f.guidCol = p.guidCol
FROM primaryTable p
WHERE p.intCol = f.intCol

Answer 3

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

У меня была сомнительная привилегия делать это раньше, и в основном мне нужно было экспортировать всю проклятую базу данных в XML. Затем у меня было Java-приложение, которое использует функцию nextLong () из java.util.Random для замены первичного ключа их новыми ключами guid. После этого я импортировал все это обратно в базу данных.

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

Answer 4

Да, я с Гленном ... Я на самом деле не решался опубликовать то же самое, прежде чем он отправил это ....

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

---

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

Отличным примером гибкости является использование имен пользователей в качестве первичного ключа. Даже если они уникальны, приятно иметь возможность их менять. Что если пользователи используют адрес электронной почты в качестве имени пользователя? Возможность изменить имя пользователя, чтобы оно не влияло на все ваши запросы, является большим плюсом, и я подозреваю, что то же самое можно сказать и о ваших GUID ....

Answer 5

НЕ ДЕЛАЙТЕ ЭТОГО! Мы начали использовать GUID, и теперь мы почти закончили переход на INT как PK; мы сохраняем GUID для целей ведения журнала (и для некоторых таблиц, например, «оборотной целостности отношений»;)), но увеличение скорости использования целочисленных значений было феноменальным.

Это действительно стало очевидным только тогда, когда счетчики строк таблицы перешли в миллионы, заметьте.

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

Answer 6

Это очень хороший выбор. Я переключился с longs на UUID для одного из своих приложений, и я не жалею об этом. Если вы используете MS SQL Server, он включен в стандарт (я использую postgresql, и он включен только в стандартную версию 8.3).

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

Answer 7

Забавно, я думаю, что нужно сделать прямо противоположное из-за другой проблемы ...

Как использовать SQLBulkCopy для таблицы с первичным ключом GUID и значением по умолчанию newsequentialid ()?

Answer 8

Я думаю, вы должны сделать это вручную. Или вы можете написать какую-нибудь утилиту для этого. Сценарий должен быть:

• Дублируйте столбцы "int" PK / FK с новыми столбцами "guid".
• Создает новые значения для столбцов "guid" PK.
• Обновите значения в столбцах "guid" FK с указанными значениями (вы найдете записи через "int" PK).
• Удалить ссылки (отношения) со столбцами "int" PK / FK.
• Создание аналогичных ссылок (отношений) со столбцами "guid" PK / FK.
• Удалить "int" столбцы PK / FK.