Datenbank Replikation

[Ongi]

Hallo,

ich habe noch mal eine Frage zur Replikation habe auch schon viel bei MSDN und soweiter dazu gelesen nur bevor ich nun die Datenbank anfange aufzusetzen würde ich mal Fragen ob noch jemand Erfahrung in die Richtung hat und evtl. Tips etc was man beachten sollte wenn man eine Datenbank aufbaut d ie später mal repliziert werden soll

schon mal Danke im vorraus

mfg

Frank Radke

[O. Helper]

Hallo Frank,

das hängt davon ab, was / wie und wohin Du Daten replizieren willst.
So gibt es schon mal als Grundlage 3 unterschiedliche Replikationsarten im MS SQL Server.

Bei der Merge-Replikation z.B. werden an den Quell-Tabellen automatisch weitere Felder angefügt; nicht jede Applikation mag solche Design-Änderung.
Usw.

[Ongi]

Hallo Olaf,

hast Recht das habe ich vergessen das ist das Problem das man oft vergisst das nicht alle wissen was man machen will ;-)

Also es soll im Grunde über Merge-Replikation laufen.
Wobei es sollche krassen Änderungen seitens der Tabelle so eigentlich nicht geben sollte

Über die Replikation soll es die Möglichkeit geben speziellen Mitarbeiten bzw. Außenstellen ein Terminalserverunabhäöngiges Werkzeug in die Hand zu geben von daher würde sich dort so nichts Ändern im Falle das sich an der Quell DB was ändert würde dies natürrlich schon soweit berückstichtigt werden das es das Programm bei den Nutzern nicht behindert.

Es sollte schon so sein das Daten in beide Richtungen repliziert werden sollen.

mfg

Frank

P.S. Wenn das dein richtiger Nachname ist, ist er fürs Forum Top geeignet ;-)

[O. Helper]

Hallo Frank,

bei einer Merge-Replikation werden an den veröffentlichten Tabellen (Artikeln) automatisch ein Feld namens "rowguid" vom Typ "uniqueidentifier" angefügt. Dazu kommt noch UNIQUE Index auf eben dieses Feld.
Dazu kommen weitere Tabellen in der Datenbank, die für die Verwaltung benötigt werden.
Die beginnen dann mit "MSmerge..." und "MSrepl...". In der Publikationsdatenbank kommen dann noch je Artikel "conflict_..." Tabellen hinzu.

Wenn in beide Richtungen repliziert werden soll, ist das schon die richtige und einzige Replikationsart und Du wirst mit den "kleinen" Design-Änderungen leben müssen.

Was zu beachten ist, ist wenn Du in den Tabellen Identity verwendest, dann wir es heikel.

Sonst gibt es für .NET noch das MS Sync Framework, mit dem man das auch noch machen könnte; aber auch da muss über weitere Felder vermerkt werden, wann wer die Daten geändert hat; geht halt nicht anders.

Und ja, das ist mein richtiger Name .. Nomen est omen..

[Ongi]

Okay wobei die zusätzlichen Felder für mich ja so eigentlich zu vernachlässigen sind da diese Ja der SQL Server selber nutzt.

Was meinst du genau mit Identity ?

Kann ich ganz normale Primärschlüssel setzen und das alles oder muss ich da was bezüglich der Replikation beachten ?

Was hällst du den für besser MS Sync Framework oder die Repli vom Server selber da ich leider nur mein "angelesenes" Wissen habe und es so praktisch noch nicht getestet habe klang für mich die Repli über MS SQL eigentlich besser geeignet.

Da du bei beiden die zusätzlichen Felder ansprichst kann es sein das ich ein wichtiges Detail vernachlässige dies bezüglich da in mein Augen mir die Felder bzw. Tabellen für die Repli doch eigentlich egal sein können ?

mfg

Frank

[O. Helper]

Um das neue Feld "rowguid" musst Du Dich wirklich nicht kümmern, das hat als Default NewID() und wird beim Insert automatisch gefüllt.
Es sein den .. es werden bei Deinen Inserts nicht explizit die Felder angegeben. Beispiel, Du hättest eine Tabelle mit 2 Felder und lässt dann hiermit

INSERT INTO Tabelle VALUES (Wert1, Wert2)

Daten einfügen. Das ist zulässige Syntax und wenn man leicht Tippfaul ist, schreibt man das schon mal so (sollte man natürlich nie).
Kommt nun das neue Feld hinzu, läuft das Statement auf Fehler, weil weniger Werte als Felder angegeben sind.
Deshalb vorher gut testen!

Man kann numerische Felder als "Identity" deklarieren und die Werte für jeden neuen Datensatz eins hochzählen lassen; macht man gerne für PrimaryKey / ID Felder.
Da die Clients (Abonnenten) in ihre Datenbank einfügen, wird es passieren, das die Ids doppelt vergeben werden und das ist dann eben ein Problem; bestenfalls schlägt der Merge fehl, schlimmstenfalls werden Daten von Datensätzen mit gleicher Id überschrieben (ich meine, letzteres geschieht).
Man kann in der Replikation Ranges je Abonnent für die Identities definieren, aber das ist so eine Sache; ist der Range ausgeschöpft, kann man keine neuen Daten einfügen.

MS Sync setzt voraus, das Du den Client selbst in .NET geschrieben hast, heisst dann, das Du Dein Programm entsprechend mit der Funktionalität selbst erweitern muss.
Die Replikation ist ein Board-Mittel vom SQL Server, das man "nur" konfigurieren musst.
Produktiv habe ich noch nichts mit dem Sync am laufen, also auch keine Erfahrungswerte.

Was Du auch noch mit einplanen muss, ist folgendes:
Ist ein Push-Abonnent nicht im Netz und somit vom SQL Server nicht erreichbar, versucht dieser bis zu 10 weitere Male, ihn zu erreichen. Danach wird die Replikation für den Abonnenten deaktiviert.
Wenn dann der wieder im Netz ist, startet somit die Repl nicht gleich & automatisch an; man muss ihn am Server wieder starten.
Pull-Abonnenten habe ich keine, von daher weiß ich momentan nicht, wie es da aussieht; müsste man mal ausprobieren.

[Ongi]

Hallo,

okay dann hatte ich es doch richtig verstanden bezüglich der Identity nur ich gehe lieber auf Nummer sicher damit man nicht im Endeffekt aneinander vorbei redet.

Also das mit dem Mergen das eben der "neuere" gewinnt habe ich auch schon so gelesen was aber auch so nicht schlimm ist dabei, den Daten die zusammengefügt werden sind immer die akutellsten auch die richtigen -> eigentlich und für diese Ausnahme kann man sowie ich das verstanden habe eigenständige Regeln bzw Ausnahmen definieren und programmierren, oder habe ich dort was falsch verstanden?

Und ich bin ja momentan noch in der Planung und Konzeptphase von daher kann ich ja noch auf alles achten und alles mit einbringen.

Und für Tips wie das mit dem insert bin ich scharf wobei ich mir sowas eigentlich nie angewöhnt habe Hoch lebe sauberrer Programmierstil

[O. Helper]

das mit dem Mergen das eben der "neuere" gewinnt habe

Mit meinem Beispiel meinte ich, auf Server und Client werden Datensätze mit gleicher Id angelegt und beim Merge überschrieben. Beispiel Kontaktdaten:
Client legt DS mit Id = 5, Kontakt = Fritz Müller
Server legt DS mit Id = 5, Kontakt = Hansi Krause
an und dazugehörende Kontaktnotizen, verlinkt über Kontakt Id 5.
Nach dem Merge ist Kontakt einheitlich mit Id 5 = Kontakt "Hansi Krause"; die Kontaktnotizen vom Client passen nicht mehr.
Deshalb verwendet man in solchen Fällen lieber "uniqueidentifier" bevorzug als Id; braucht mehr Speicher, vermeidet aber solche Probleme.

für diese Ausnahme kann man sowie ich das verstanden habe eigenständige Regeln bzw Ausnahmen definieren und programmierren

Es besteht die Möglichkeit, vorhandene "Konfliktlöser" (wenn mehrere Quellen Daten geändert haben) zu konfigurieren oder sogar eigene zu Programmieren; Du solltest langsam auch den dazugehörenden Aufwand bei Deinen Überlegungen in den Fokus zu nehmen.

Hoch lebe sauberrer Programmierstil

Ganz genau; mach zunächst etwas mehr Aufwand, aber alles andere rächt sich früher oder später.

[Ongi]

Bei den "uniqueidentifier" habe ich aber so keine Nachteile im Programm selber kann also mit ihnen arbeiten als wenn ich eine ganz normale hochzählende ID habe ? Oder muss ich was beachten ?

; Du solltest langsam auch den dazugehörenden Aufwand bei Deinen Überlegungen in den Fokus zu nehmen.

Das dort hinter eine Menge Aufwand steckt ist klar doch das Projekt soll wenn es abgeschlossen ist eben in verschiedensten Version und Größen Ordnung beim Kunden laufen von daher ist ein wenig mehr Programmier Aufwand in der Entwicklungsphase einfacher als später die ganzen Fehler beim Kunden mit Updates zu beheben

Ich kann dir ja falls du Interesse dran hast mal per PM zukommen lassen worum es eigentlich geht.


Und nochmals vielen Dank für die schnelle und kompetente Hilfe

[O. Helper]

Bei den "uniqueidentifier" habe ich aber so keine Nachteile im Programm selber

IDs werden in Programmen / Business Logik direkt nicht verwendet; sie dienen nur dazu Daten eindeutig zu kennzeichen und Beziehungen herzustellen; also Primary & Foreign Key.
Von daher ist der Typ eher nebensächlich.

[Ongi]

Okay erstmal vielen Dank hast mir echt geholfen