Импорт данных из одной базы данных в другую базу данных слегка измененной схемы

Question

У меня есть ситуация, когда у меня есть база данных с несколькими таблицами и большим количеством записей в них, скажем,

Database 1
 - tbl1
 - tbl2
 - tbl3
 - tbln

Таблицы имеют отношения PK-FK.Тип данных PK имеет тип «uniqueIdentifier».Недавно я прочитал, что использование uniqueIdentifier в качестве типа данных может снизить производительность, и всегда лучше иметь целочисленный тип для PK, поскольку это может привести к более быстрым индексам.

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

Может ли кто-нибудь помочь мне с наилучшим подходом к решению этой проблемы - после обновления данные и отношения PK-FK должны оставаться неизменными.

Это наш подход:

• Создать новую таблицу [DB2] с типом данных PK в качестве целочисленного идентификатора
• Добавить все отношения PK-FK
• Напишите программу для переноса данных из DB1 в DB2.

Мы знаем, что это не маленькая задача, потому что она включает в себя множество таблиц с отношениями PK-FK

• Есть ли лучший способ сделать это?
• Можем ли мы сделать изменение / обновление самой исходной базы данных, не создавая вторую базу данных, а затем перенося в нее данные?

Любая помощь приветствуется.Спасибо.

Answer 1

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

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

Самая большая проблема с использованием uniqueidentifier заключается в том, как генерировать новые значения идентификаторов, особенно если первичный ключ находится в кластеризованном индексе.Если вы используете NEWID(), это довольно случайно, поэтому он может вставляться в любое место в табличном пространстве, вызывая ненужные разбиения страницы.Использовать NEWSEQUENTIALID() лучше, поскольку он создает последовательные уникальные идентификаторы, но при каждом запуске базы данных он имеет новое случайное начальное число, поэтому он также не всегда добавляется в конец таблицы.

Лучшее решение IMHOдолжен использовать GUID в стиле COMB, который имеет часть, основанную на временной метке (которая, конечно, монотонно увеличивается), и часть, которая является случайной.(В качестве крошечного побочного эффекта вы можете декодировать часть метки времени, если вам когда-либо понадобится узнать, когда произошла ВСТАВКА, при условии, что информация также не сохраняется в другом месте.)

Вот пример функции COMB:

CREATE FUNCTION [dbo].NewCOMB(@GUID uniqueidentifier)
RETURNS uniqueidentifier AS BEGIN
   RETURN CAST(
       CAST(NEWID() AS binary(10)) 
       + CAST(GETDATE() AS binary(6)) 
     AS uniqueidentifier)
END;

Вот отличная статья на эту тему, немного устаревшая, но все же хорошая:

http://www.informit.com/articles/article.aspx?p=25862&seqNum=7

Если вы обнаружите, что должны сменить лошадей, сделайте это следующим образом:

• Добавить новые столбцы идентификаторов в каждую таблицу под другим именем
• Заполнить их
• При необходимости проиндексировать их
• Снять ограничения таблицы настарые столбцы
• Добавление новых ограничений для новых столбцов
• Удаление старых столбцов
• Переименование новых столбцов в старые имена (при необходимости)