репликация между две таблици с различни имена и които имат различни имена на колони. Възможно ли е да се създаде такава репликация

Очевидно отговорът е:„Когато дефинирате статията, ще трябва да зададете @vertical_partition параметър на true и след това добавете колоните, които искате с sp_articlecolumn ."

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

Други идеи за мозъчна атака:

• Можете да създадете нова изходна таблица, която съответства на целевата таблица, и да използвате тригер, за да поддържате изходната таблица синхронизирана.
• Избутайте изходната таблица непокътната до дестинацията и направете MERGE в целевата база данни.
• Репликацията може наистина да не е правилното решение тук. Какви са бизнес правилата и изискванията, които изискват това да бъде направено? Мислили ли сте да използвате SSIS?
• Ако ИМА нужда двете таблици да бъдат в точна синхронизация през цялото време, тогава какъв е каналът за промени в изходната таблица - приложение? Почти звучи така, сякаш вашето приложение се нуждае от ново ниво на абстракция, слой за запис на данни, който знае как да пише на два източника едновременно.

Опитът да се поддържат данни синхронизирани между две различни бази данни може да бъде проблем. Може да има всякакви фини проблеми с условията на състезание, липса на разпределени транзакции (засягащи последователността и отговора на неуспехи), проблеми със заобиколните решения, създадени да се справят с липсата на разпределени транзакции, и така нататък и така нататък. Можете ли вместо това да създадете свързан сървър и някои изгледи, които действително правят данните в една база данни достъпни в реално време от другата?

Моля, кажете ни повече за вашите изисквания и защо трябва да направите това.

Актуализация

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

BEGIN TRAN;

DELETE D
FROM LinkedServer.dbo.Dest D WITH (TABLOCKX, HOLDLOCK)
WHERE
   NOT EXISTS (
      SELECT *
      FROM Source S
      WHERE D.Key = S.Key
   );

UPDATE D
SET
   D.Col1 = S.Col4,
   D.Col2 = S.Col5,
   D.Col3 = S.Col6,
   D.Col4 = S.Col7,
FROM
   LinkedServer.dbo.Dest D
   INNER JOIN Source S ON D.Key = S.Key
WHERE
   D.Col1 <> S.Col4
   OR EXISTS (
      SELECT D.Col2, D.Col4
      EXCEPT
      SELECT S.Col3, S.Col6
   ); -- or some other way to handle comparison of nullable columns

INSERT LinkedServer.dbo.Dest (Col1, Col2, Col3)
SELECT Col4, Col5, Col6
FROM Source S WITH (TABLOCK, HOLDLOCK)
WHERE
   NOT EXISTS (
      SELECT *
      FROM LinkedServer.dbo.Dest D
      WHERE S.Key = D.Key
   );

COMMIT TRAN;

Може да откриете, че е по-добре да натиснете цялата таблица и да извършите операцията по сливане на целевия сървър.

Подсказките за заключване, които поставих в първата заявка, са важни, ако искате да имате последователна моментна снимка към определен момент. Ако това не ви интересува, извадете съветите за заключване.

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