SQL Server - Кой е най-добрият начин за промяна на тип данни на PK?

В момента имам база данни с около 20 референтни таблици, т.е. неща като продукти, активи, депа, потребители и т.н. Тази информация се съхранява в централна база данни и се изтегля на PDA на инженери, които са на път. Всяка таблица в моята база данни има PK на UniqueIdentifier (т.е. GUID).

Разбрах след 2 години разработване на продукта, че никога не правя и никога няма да трябва да редактирам която и да е от тези референтни таблици. Следователно няма нужда те да имат UniqueIdentifier като първични ключове.

Тъй като сериализирам всичките си колекции, преди да ги изпратя на PDA през моята уеб услуга, действителните сериализирани данни са огромни поради дължината на 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 поради разпределения характер на вашето приложение (PDA) и че може би първоначалното намерение може да е било да се добавят нови данни от тези PDA, в който случай GUID са идеални. Недостатъкът е, че не можете да индексирате по GUID.

Моето предложение е да не използвате int самоличност като начало. Първо, деактивирайте вашите FK. Добавете нова колона, която е INT (не идентичност) за всички препратки към този PK (т.е. всички таблици, които също имат FK към него). След това за всеки GUID създайте нов int (следващата стойност) и го вмъкнете срещу guid и всички препратки към guid в други таблици. След това включете нови FK за ints и след това преместете своя 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

Е, това, което не разбирам е, че от една страна заявявате, че не се нуждаете от колоните за идентификатор, но от друга ги изпращате чрез вашата уеб услуга.

Така че първо бих разгледал моите заявки, за да видя какво е извлечено и да оптимизирам там по отношение на върнатия набор от резултати.

Промяната на PK е голямо усилие, но с помощта на "SQL Compare" може да се направи.

person Dimi Takis    schedule 22.01.2009

arrow_upward
0
arrow_downward

Докато имате някакво поле (или набор от полета), което е уникално, можете просто да присвоите отново PK на това поле. т.е. ако нямате нужда от guid, вероятно нямате нужда и от сурогатен ключ за ИДЕНТИЧНОСТ. Най-лесното нещо, което можете да направите като цяло, е просто да използвате PK на една или повече ненулеви съществуващи колони, които са уникални.

В противен случай просто добавете колона IDENTITY и преназначете PK към нея. (Ще се попълни, когато запишете променената таблица.) След това можете да изтриете колоната с guid.

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

Ако нищо от това не отговаря на вашата ситуация, публикувайте отново с повече подробности. Това може да стане с малко суетене или безпокойство.

(Не съм сигурен защо смятате, че имате нужда от уникални идентификатори за вашите първични ключове, дори ако таблиците трябваше да бъдат редактирани, BTW.)

person dkretz    schedule 22.01.2009