Często istnieje potrzeba synchronizowania danych z tabel głównych w jednej bazie danych w celu klonowania tabel w innych bazach danych, często na innych serwerach. Rozważmy na przykład przypadek, w którym system zaplecza zarządza danymi zapasów, a dane dotyczące zapasów muszą być ostatecznie przesłane do jednej lub większej liczby baz danych, które są częścią aplikacji witryny sieci Web.

Dane źródłowe w systemie zaplecza są mocno znormalizowane, z dziesiątkami tabel i ograniczeniami klucza obcego. Jest to dobrze zaprojektowany system OLTP RDBMS. Wiele z tych tabel zawiera miliony wierszy. Konieczne jest regularne przesyłanie tych danych do innych baz danych. Tak często, jak to możliwe; opóźnienie może być tolerowane. Przede wszystkim niezbędny jest maksymalny czas pracy zarówno zaplecza, jak i zdalnych baz danych.

Używam SQL Server i jestem zaznajomiony ze śledzeniem zmian, rowversionem, wyzwalaczami i tak dalej. Wiem, że Microsoft mocno naciska na replikację, SyncFx i SSIS dla tych scenariuszy. Istnieje jednak duża różnica między dokumentami dostawcy a przeglądami zalecającymi technologie i rzeczywistą implementację, wdrożenie i konserwację rozwiązania. W świecie SQL Server replikacja jest często postrzegana jako rozwiązanie pod klucz, ale próbuję odkrywać alternatywne rozwiązania. (Istnieje obawa, że ​​replikacja jest trudna do administrowania, utrudnia zmianę schematu, a w przypadku, gdy ponowna inicjalizacja jest kiedykolwiek wymagana, wystąpiłyby duże przestoje w systemach krytycznych).

Jest wiele gotchas. Ze względu na złożone relacje klucza obcego między dużą liczbą tabel, ustalenie kolejności wykonywania przechwytywania lub stosowanie aktualizacji nie jest trywialne. Ze względu na unikatowe indeksy, dwa wiersze mogą być połączone w taki sposób, że aktualizacja wiersza nie działa nawet (trzeba wykonać aktualizacje pośrednie każdego wiersza przed ostateczną aktualizacją). Niekoniecznie muszą to być stopery, ponieważ unikalne indeksy często można zmienić na zwykłe indeksy, a klucze obce można wyłączyć (chociaż wyłączenie kluczy obcych jest bardzo niepożądane). Często usłyszysz „po prostu” skorzystaj ze śledzenia zmian SQL 2008 oraz SSIS lub SyncFx. Tego rodzaju odpowiedzi naprawdę nie oddają praktycznych trudności. (I oczywiście klienci naprawdę mają trudności z zawinięciem głowy nad tym, jak kopiowanie danych może być tak trudne, co jeszcze bardziej pogorszy sytuację).

Ten problem jest bardzo ogólny: wykonaj jednokierunkową synchronizację wielu pokrewnych tabel bazy danych z dużą ilością wierszy. Prawie wszyscy zaangażowani w bazy danych muszą radzić sobie z tego rodzaju problemami. Białe księgi są powszechne, trudno znaleźć praktyczną wiedzę. Wiemy, że może to być trudny problem, ale praca musi zostać wykonana. Posłuchajmy, co zadziałało (i czego unikać). Opowiedz o swoich doświadczeniach z produktami Microsoft lub produktami innych dostawców. Ale jeśli osobiście nie przetestowałeś rozwiązania z dużą liczbą mocno powiązanych tabel i wierszy, powstrzymaj się od odpowiadania. Zachowajmy to w praktyce - nie teoretyczne.