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

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

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

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

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

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


database sql-server primary-key sql-server-2005
person djdd87    schedule 22.01.2009    source источник

Ответы (4)


arrow_upward
2
arrow_downward

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

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

Надеюсь, что это было не так уж и плохо.

person DarkwingDuck    schedule 22.01.2009

arrow_upward
3
arrow_downward

Первый - 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

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

person mson    schedule 22.01.2009

arrow_upward
0
arrow_downward

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

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

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

person Dimi Takis    schedule 22.01.2009

arrow_upward
0
arrow_downward

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

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

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

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

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

person dkretz    schedule 22.01.2009