Каков наиболее эффективный способ переноса этих данных на Sql Server? - PullRequest
Новая
       7

Каков наиболее эффективный способ переноса этих данных на Sql Server?

0 голосов
/ 07 декабря 2010

Вот наша текущая таблица 

CREATE TABLE Visitor
(
   VisitorID  bigint,
   DayPhone   varchar(50),
   NightPhone varchar(50)
)

Я хочу перенести эти данные в отдельную таблицу: 

CREATE TABLE VisitorPhone
(
   VisitorID      bigint,
   Label          varchar(50), --Day, Night, Work, Cell, etc.
   Phone          varchar(50)
)

Я думал, что наиболее эффективным способом было бы сделать это: 

INSERT INTO VisitorPhone(VisitorID, Label, Phone)
SELECT VisitorID, 'day', DayPhone FROM dbo.Visitor WHERE DayPhone IS NOT NULL AND DayPhone <> ''

INSERT INTO VisitorPhone(VisitorID, Label, Phone)
SELECT VisitorID, 'night', NightPhone FROM dbo.Visitor WHERE NightPhone IS NOT NULL AND NightPhone <> ''

Какие у меня есть другие варианты? Мы говорили обо всем, начиная с функций Sql CLR, Temp Tables, ADO.NET, вы называете это. Какой действительно самый эффективный способ сделать это? Имейте в виду, что DayPhone и NightPhone не являются частью индекса, и что у меня есть записи о посетителях 16MM +, которые будут находиться в диапазоне от ~ 16MM до ~ 32MM записей VisitorPhone.

1 Ответ

1 голос
/ 08 декабря 2010

Я бы сделал миграцию, как вы уже предложили. Проблема в том, что строка посетителя генерирует ноль, одну или две строки в таблице VisitorPhone. Если бы это был Oracle, у вас был бы синтаксис INSERT ALL, который позволял вам делать именно это. Может быть, какой-то похожий синтаксис доступен в SQL Server?

Любой процедурный подход, вероятно, будет превзойден подходом, основанным на множестве.

Вы можете сделать что-то сложное, например, присоединиться к фиктивной таблице и определить, сколько раз будет дублироваться каждая строка посетителя (0 = не имеет телефона, 1 имеет либо телефон день / ночь, 2 имеет оба). Затем вы будете использовать логику case-when, чтобы определить, как кодировать строку.

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

Только потом обязательно создайте индексы.

...