replikacja między dwiema tabelami o różnych nazwach io różnych nazwach kolumn. Czy można stworzyć taką replikację?

Najwyraźniej odpowiedź brzmi:„Kiedy definiujesz artykuł, musisz ustawić @vertical_partition parametr na true, a następnie dodaj żądane kolumny za pomocą sp_articlecolumn ”.

Muszę jednak zapytać, dlaczego to robisz. Moim zdaniem replikacja nie jest ogólnym narzędziem do przenoszenia danych między różnymi bazami danych, ale do utrzymywania synchronizacji dwóch identycznych baz danych.

Inne pomysły na burzę mózgów:

• Możesz utworzyć nową tabelę źródłową, która pasuje do tabeli docelowej, i użyć wyzwalacza, aby utrzymać synchronizację tabeli źródłowej.
• Przesuń nienaruszoną tabelę źródłową do miejsca docelowego i wykonaj MERGE w docelowej bazie danych.
• Replikacja może nie być tutaj właściwym rozwiązaniem. Jakie są zasady i wymagania biznesowe, które tego wymagają? Czy rozważałeś użycie SSIS?
• Jeśli istnieje potrzeba, aby obie tabele były przez cały czas w dokładnej synchronizacji, to jaki jest kanał zmian w tabeli źródłowej — aplikacja? Wygląda na to, że Twoja aplikacja potrzebuje nowego poziomu abstrakcji, warstwy zapisu danych, która wie, jak pisać do dwóch źródeł jednocześnie.

Próba utrzymania synchronizacji danych między dwiema różnymi bazami danych może stanowić problem. Mogą występować różnego rodzaju subtelne problemy z warunkami wyścigu, brakiem transakcji rozproszonych (wpływającymi na spójność i reakcję na awarie), problemy z obejściami stworzonymi w celu radzenia sobie z brakiem transakcji rozproszonych i tak dalej i tak dalej. Czy możesz zamiast tego utworzyć połączony serwer i niektóre widoki, dzięki którym dane w jednej bazie danych będą dostępne w czasie rzeczywistym z drugiej?

Powiedz nam więcej o swoich wymaganiach i dlaczego musisz to zrobić.

Aktualizacja

Jeśli wybierasz się na trasę ręcznej aktualizacji, pamiętaj, że nie możesz masowo zastosować operacji wstawiania, aktualizowania i usuwania okresu. Musisz je stosować pojedynczo, w kolejności . Jeśli zamiast tego pracujesz z stanem bieżącym zamiast pośrednich operacji na danych, możesz wykonać wszystkie wiersze naraz. Pokażę ci przykład MERGE, a nie odtwarzanie historii.

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;

Może się okazać, że lepiej będzie wypchnąć całą tabelę i wykonać operację scalania na serwerze docelowym.

Wskazówki dotyczące blokad, które umieściłem w pierwszym zapytaniu, są ważne, jeśli zamierzasz mieć spójną migawkę z punktu w czasie. Jeśli ci to nie zależy, usuń wskazówki dotyczące blokowania.

Jeśli okaże się, że aktualizacje na serwerze połączonym są powolne, wypchnij całą tabelę w jednym kawałku do tymczasowej tabeli pomostowej na serwerze zdalnym i wykonaj MERGE w skrypcie całkowicie na serwerze zdalnym.