Die beste Technologie, um Daten zwischen verschiedenen Datenbankschemata zu synchronisieren?

Question

Ich habe eine vorhandene SQL Server 2005-Datenbank, die Accounting / Inventar-Anwendung läuft. Wir suchen einen neuen Online-Bestellung Rahmen bei Verwendung -., Die eine eigene Datenbank hat

Wenn wir diesen neuen Rahmen zu verwenden, müssen wir die Online-Bestelldaten (Inventar, Preise, Bestellungen, Kunden) übertragen - fast in Echtzeit - auf und ab, unsere bestehenden Inventardatenbank. Die Übertragung der Daten muss nicht in Echtzeit, aber es hat schnell zu sein. Beide Datenbanken werden in SQL Server sein.

Also meine Frage ist ... was ist der beste Weg, um Daten TRANSER hin und her zwischen zwei Datenbanken mit unterschiedlichen Schemata haben?

Replikation? SSIS? Was würden Sie vorschlagen, und warum?

Jede mögliche Hilfe würde geschätzt!

Answer 1

Persönlich würde ich läuft aus diesem Alptraum weg, so schnell wie ich kann. Da Sie diese Online-Bestellung gekauft noch nicht haben, würde ich vorschlagen, dass mit der vorhandenen Anwendung der Daten synchron hält nicht zu tun, so etwas ein triftiger Grund ist. Wenn Sie diese kaufen werden Sie ewig bereuen, wie Sie Ihre Daten muckte up wird werden und wie viel Zeit und Geld Sie ausgeben versuchen, die Dinge zu bekommen richtig zu arbeiten. Das ist eine Katastrophe warten geschehen. Schmetzen am Ende Menschen Artikel angeblich in iventory bestellen hat, wenn es keine im Lager ist. Mach das nicht. Dies ist eine Garantie für verärgerte Kunden und wütend Manager. Weit weit billiger im Laufe der Zeit einige Entwickler anstellen, um Ihre eigene Online-Bestellung zusammen zu stellen, die Ihre Datenbank zugreift. Wenn sie vor über Ihre Einwände gehen, würde ich meinen Lebenslauf aktualisieren.

Answer 2

Die Business Rules sind die Hard Part

Ein-Wege-Synchronisation? Zwei-Wege-Synchronisation? Echtzeit-Push? Nightly-Updates? Dump und neu zu laden? Vergleichen und aktualisieren? Konfliktlösung? Welche Seite gewinnt? Schieben Nur-Lese-Info einen Weg, und um Informationen in die andere Richtung? Was über Änderungen / Stornierungen / etc? Auftragsstatus Lassen Sie sich zurückgeschoben?

Sie können sehen, wo ich hier werde. Technologie ist eine sekundäre Frage.

Aufgrund der Geschäftsregeln Problem, und da die beiden Systeme unterschiedliche Schemata (und andere Zwecke), das ist kein Standard-Daten bewegen, und die meisten der „Standard“ Antworten (Replikation, Protokollversand, etc.) sind vom Tisch.

Es gibt Frameworks da draußen entwickelt, um mit diesem zu helfen, wie Microsoft BizTalk oder Scribe Insight . Dies sind umständlich und teuer, aber.

Es ist nicht allzu schwierig, ein benutzerdefinierten Warteschlange-ing System entweder auf SQL Basis zu erstellen Trigger oder geplant Schübe (je nach Bedarf) in C # oder Ihrer bevorzugten Sprache. Das ist wahrscheinlich der Weg, den ich gehen würde. Es wäre wahrscheinlich beinhalten eine dritte „Transfer“ Datenbank, um die Warteschlange von Änderungen von der einen Seite, und ein Modul gemacht zu halten, die Geschäftsregeln anzuwenden und die Daten an die anderen schieben.

Answer 3

Aus eigener Erfahrung würde ich nur die Replikation verwenden, wenn es keine andere Wahl. Sie müssen es reißen für jede Schemaänderung nach unten und es hat eine Tendenz, nur die Luft sprengen.

Für diese, würde ich wahrscheinlich verwenden, SSIS. Es ist ziemlich einfach, ein Transformationspaket zu bauen und relativ einfach zu halten.

Answer 4

Replikation funktioniert gut, und wenn es zwei Art und Weise ist, könnte es die einzige sinnvolle Option sein, da die Konfliktlösung eingebaut ist.

Wenn du gehst, one-way, SSIS oder Trigger auf Tabellen wäre fein, und würde drücken Sie die Daten in Echtzeit (für Trigger) oder bei was auch immer gewünschten Intervall (SSIS). Der Vorteil SSIS wäre, dass es ein Hintergrundprozess ist, während Auslöser möglicherweise Transaktionen auf der Angebotsseite halten konnten, während sie die Daten drücken.

Wenn Sie schauen, große Datenmengen zu bewegen, gibt es andere Produkte gibt, die es für Sie tun kann, aber wenn es nicht zu viele Daten ist, eine Lösung SQL Server-Tools sollten alle müssen Sie tun.