SQL Server - Какой лучший способ изменить тип данных PK?

Question

В настоящее время у меня есть база данных, содержащая около 20 справочных таблиц, например, продукты, активы, склады, пользователи и т. Д. Эта информация хранится в центральной базе данных и загружается в КПК инженеров, которые находятся в пути. , Каждая таблица в моей базе данных имеет PK UniqueIdentifier (то есть GUID).

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

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

В любом случае, приступая к делу - я хочу изменить все PK таблиц на IDENTITY Ints. Есть ли какой-нибудь простой способ сделать это, или мне придется пойти по пути разделения всех FK, создания временных таблиц, а затем написания некоторого программного обеспечения для переназначения данных?

Заранее спасибо.

Answer 1

Первый - LOL. Я знаю довольно много других людей в вашей компании ... «Ух ты - GUID - это круто, я собираюсь использовать их повсюду ...» По крайней мере, вы узнаете одну из проблем с этим маршрутом.

Второе - эти команды могут оказаться полезными:

exec sp_MSforeachtable 'ALTER TABLE ? NOCHECK CONSTRAINT ALL' 

<do stuff here>

exec sp_MSforeachtable 'ALTER TABLE ? CHECK CONSTRAINT ALL' 

Третий - часть, где говорится - делайте вещи здесь -

1) add an int autoincrementing identity column to ref table
2) set the current fk guid in data tables to the db key you just created in step 1
3) rinse/repeat for each ref table/data table combination
4) after all is done, refactor code to use id (int) instead of guid

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

Answer 2

Если у вас есть ФК, ссылающиеся на ваши ПК, у вас большие проблемы. Я предполагаю, что вы использовали GUID из-за распределенной природы вашего приложения (КПК) и что, возможно, первоначальная цель заключалась в добавлении новых данных из этих КПК, и в этом случае GUID являются идеальными. Недостатком является то, что вы не можете индексировать GUID.

Мое предложение не состоит в том, чтобы начинать с идентичности. Прежде всего, отключите ваши FKs. Добавьте новый столбец INT (не тождество) для всех ссылок на этот PK (то есть для всех таблиц, которые также имеют FK). Затем для каждого GUID создайте новый int (следующее значение) и вставьте его в guid, а также все ссылки на guid в других таблицах. Затем включите новые FK для целых, а затем перенесите свой PK в новый столбец int. В конце удалите столбцы GUID и перестройте индекс.

Надеюсь, что это не слишком искажено.

Answer 3

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

Итак, я сначала посмотрю на мои запросы, чтобы увидеть, что извлекается, и оптимизировать их с точки зрения возвращаемого набора результатов.

Смена PK - это большое усилие, но с помощью «SQL Compare» это можно сделать.

Answer 4

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

В противном случае просто добавьте столбец IDENTITY и переназначьте ему PK. (Заполняется при сохранении измененной таблицы.) Затем вы можете удалить столбец с помощью guid.

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

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

(Я не уверен, почему вы думали, что вам нужны уникальные идентификаторы для ваших первичных ключей, даже если таблицы должны были редактироваться, кстати).