2009-01-16 16 views
9

Mam istniejącą bazę danych SQL Server 2005, która uruchamia naszą aplikację księgową/magazynową. Szukamy możliwości korzystania z nowej struktury zamówień on-line, która ma własną bazę danych.Najlepsza technologia synchronizacji danych między różnymi schematami bazy danych?

Jeśli wykorzystamy tę nową strukturę, będziemy musieli przenieść dane do składania zamówień on-line (zapasy, ceny, zamówienia, klienci) - prawie w czasie rzeczywistym - do iz naszej istniejącej bazy danych magazynowych. Przekazywanie danych nie musi odbywać się w czasie rzeczywistym, ale musi być szybkie. Obie bazy danych będą w SQL Server.

Moje pytanie brzmi: jaki jest najlepszy sposób na przechodzenie danych pomiędzy dwiema bazami danych, mając różne schematy?

Replikacja? SSIS? Co byś zasugerował i dlaczego?

Każda pomoc zostanie doceniona!

Odpowiedz

8

Osobiście uciekłbym z tego koszmaru tak szybko, jak tylko mogłem. Ponieważ nie kupiłeś jeszcze tego zamówienia online, sugerowałbym, że przechowywanie danych w synchronizacji z istniejącą aplikacją jest ważnym powodem, dla którego nie można tego zrobić. Jeśli to kupisz, będziesz wiecznie żałować, jak zmarnują się Twoje dane i ile czasu i pieniędzy poświęcisz na próbę poprawnego działania. To jest katastrofa, która czeka, by się wydarzyć. Przekonasz się, że ludzie zamawiają przedmioty rzekomo w ekwipunku, kiedy ich nie ma w magazynie. Nie rób tego. Jest to gwarancja gniewnych klientów i złych menedżerów. Znacznie taniej z biegiem czasu, aby wynająć deweloperów do złożenia własnego zamówienia online, dostęp do bazy danych. Jeśli posuną się naprzód w sprawie swoich zastrzeżeń, zaktualizuję moje CV.

+0

Werbalizujesz moje obawy, że spędzasz więcej czasu na pisaniu (i obsłudze kodu) w celu synchronizowania danych - niż sam pisałbym samą aplikację sieciową! – Clinemi

0

replikacji działa dobrze, a jeśli jest to dwukierunkowy, może być jedyną realną opcją, ponieważ rozwiązywanie konfliktów jest zbudowany.

Jeśli jedziesz w jedną stronę, SSIS lub wyzwala na stołach będzie w porządku, i przesunie dane w czasie rzeczywistym (dla wyzwalaczy) lub w dowolnym odstępie czasu (SSIS). Zaletą SSIS jest to, że jest to proces działający w tle, podczas gdy wyzwalacze mogą potencjalnie wstrzymywać transakcje po stronie podaży, podczas gdy przesyłają dane.

Jeśli chcesz przenieść ogromne ilości danych, istnieją inne produkty, które mogą to zrobić dla Ciebie, ale jeśli to nie jest za dużo danych, rozwiązanie wykorzystujące narzędzia SQL Servers powinno zrobić wszystko, czego potrzebujesz.

1

Z własnego doświadczenia korzystałbym tylko z replikacji, gdyby nie było innego wyboru. Musisz go zniszczyć, aby zmienić schemat, i ma tendencję do wysadzania w powietrze.

Najprawdopodobniej skorzystam z SSIS. Jest dość łatwy do zbudowania pakietu transformacji i dość prosty w utrzymaniu.

11

reguł biznesowych są Najtrudniejsze

Jednokierunkowa synchronizacja? Dwukierunkowa synchronizacja? Push w czasie rzeczywistym? Nocne aktualizacje? Zrzuć i przeładuj? Porównaj i zaktualizuj? Rozwiązanie konfliktu? Która strona wygrywa? Przesyłaj informacje tylko do odczytu w jedną stronę i zamawiaj informacje w drugą stronę? A co ze zmianami/anulacjami/itd.? Czy statusy zamówień są odrzucane?

Możesz zobaczyć, dokąd zmierzam. Technologia to kwestia drugorzędna.

Z powodu problemu reguł biznesowych, a także dlatego, że oba systemy mają różne schematy (i różne cele), nie jest to standardowy ruch danych i większość "standardowych" odpowiedzi (replikacja, wysyłka dziennika itp.) są poza stołem.

Istnieją ramy zaprojektowane, aby pomóc w tym, jak Microsoft BizTalk lub Scribe Insight. Są jednak kłopotliwe i drogie.

Tworzenie niestandardowego systemu kolejkowania w oparciu o wyzwalacze SQL lub zaplanowane wypychania (w zależności od potrzeb) w języku C# lub w ulubionym języku nie jest trudne. To pewnie ta trasa. Prawdopodobnie obejmowałoby to bazę danych "transferu" trzeciego, aby pomieścić kolejkę zmian dokonanych przez jedną stronę, oraz moduł do zastosowania reguł biznesowych i przekazania danych do drugiej.

+0

Tak, będą obowiązywać reguły biznesowe, więc Twoje punkty dotyczące replikacji i wysyłki dziennika są dobrze zrobione. Zamówienia będą pochodzić z ramowej bazy danych, a wszystko inne będzie wchodzić w ramy. Niestandardowy kod kolejki lub SSIS wyglądają tak, jakby działały w tym scenariuszu. – Clinemi

+0

Dzięki za twój wkład. Dałem wam głos, ponieważ wasze punkty były bardzo pomocne w podjęciu decyzji o niestosowaniu ram. – Clinemi