Сохраненная процедура для слияния таблиц

Question

Я делаю некоторые работы с клиентом в своем datamart по продажам, добавляя новое соединение с их ERP. Клиент сохранил старую базу данных («888») только для производства и создал новую базу данных «999» для продаж. Вся история остается в 888 году до 31 декабря, а новые продажи - в 999 году с 1 января 2016 года.

Теперь у меня есть все таблицы и представления SQL Server, настроенные для опроса ERP для 888 и 999 с использованием новых таблиц и представлений в качестве реплик того, что у нас было ранее всего за 888. Теперь я хочу объединение 888 и 999, поэтому у нас есть один набор данных.

Мне очень удобно создавать таблицы для таблиц fact, так как не должно быть дубликатов записей, однако хотелось бы, чтобы некоторые рекомендации по тусклым таблицам.

Клиенты и продукты были скопированы из 888 в 999 в ERP, так что я абсолютно будет есть дубликаты, но я только хочу иметь одну версию из 999. Тем не менее, говорят, что клиент будет удален из 999, я все еще будет иметь историю с 888, поэтому ее необходимо включить.

Я думаю, что я не могу на самом деле сделать объединение (из-за дубликатов), скорее я думаю, что мне нужно создать какую-то процедуру, которая вставляет все записи из таблицы 999, а затем обрабатывает 888 против этого, добавив записи, где они не существуют в цели.

Моя проблема в том, что я действительно не знаю, как написать такую ​​хранимую процедуру. Если я думаю о размере Customer в качестве примера, первичный ключ равен [Order_Debtor], а пример описательного столбца - [Order_Debtor_Description].

То, что я ищу, это руководство по написанию кода, который будет делать вставку из 999.customer в merged.customer, а затем проверку и вставку из 888.customer в merged.customer, когда он не существует в merged.customer.

Answer 1

Данные таблицы z888Customer и z999Customer, которые уже были заселены

Как я понимаю, здесь случаи вы описали для де-множительных данных:

Case z888Customer  z999Customer   Use Data From 
A  123     (doesn't exist)  888 
B  (doesn't exist)  789     999 
C  456     456     888 

Так один из способов сделать это было бы создать представление, содержащее это:

-- Case A - only 888 records that are not in 999 
SELECT Debtor_ID, Field1, Field2 
FROM z888Customer 
WHERE NOT EXISTS (
    SELECT * 
    FROM z999Customer 
    WHERE z999Customer.Debtor_ID = z888Customer.Debtor_ID 
    ) 
UNION ALL 
-- Case B and C 
SELECT Debtor_ID, Field1, Field2 
FROM z999Customer 

Говорят, что представление называется LoadCustomers вы можете загрузить только новые Wi th:

INSERT INTO CustomerDimension (Field1,Field2,DebtorID) 
SELECT Field1,Field2,DebtorID FROM LoadCustomers 
WHERE NOT EXISTS (
    SELECT * 
    FROM DimCustomer 
    WHERE DimCustomer.DebtorID = LoadCustomer.DebtorID 
) 

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

В качестве ключа соответствия мы используем Debtor_ID. Таким образом, вы должны смотреть на эти вещи:

• Если DebtorID 63 будет удален из БД, но затем пересоздался как новый полностью должника в том, что Д.Б. повторное использование и тот же идентификатор, что не отразится - старый останутся прежними
• Если у вас есть две разные базы данных, я гарантирую, что они расходятся.Я предлагаю вам изменить «историческую» базу данных только для чтения (ALTER DATABASE SET READ_ONLY, также установить файлы в файловой системе только для чтения), иначе люди будут играть, и у вас будут проблемы
• Я только предоставил случай INSERT выше. Нет обновления. Это означает, что если должник меняет имена в источнике, он не будет отображаться в вашем хранилище данных, поскольку только шаг вставки не является обновленным.

Это связано с вашей «репликацией», то есть вы объединяетесь данные, и вы должны принять решение о правилах для каждого случая

Ну и еще одна вещь рассмотреть возможность использования схемы разделите таблицы (не Аз префикс)

таким образом, вы размер может быть dbo.DimCustomer и ваша постановка может быть staging.888Customer. Тем не менее, зачастую постановка представляет собой другую базу данных.