Was passiert mit Links bei Replikation?
-
Hallo Forum
ich habe eine Datenbank (SQl Server 2000) die hauptsächlich aus Links zu bestimmten Dokumenten besteht (.pdf, .doc, Links zu anderen Datenbanken). Wenn ich diese Datenbank repliziere auf einen anderen Rechner, der nicht an diesem Netzwerk hängt, also somit keinen Zugriff mehr auf die Links hat, dann sind die ja unbrauchbar? Ist es möglich bei der Replikation die Daten, auf die verwiesen wird, irgendwie mit zu kopieren also sozusagen die Links auszuwerten? Was ist da eine sinnvolle Lösung?
Vielen Dank für eure Tipps.
-
Dann leg die Dokumente doch in die DB ab wenn die anderen Knoten die Doks lesen können sollen.
-
Hmm, o.k., ich glaube ich muss genauer erklären was ich meine. Unser Kunde hat verschiedenste Dokumente auf seinem Server, und die Datenbank soll nun das Auffinden dieser Dokumente vereinfachen. Sie ist also eigentlich eine Linksammlung zu verschiedenster Dokumente. Sie hat allerdings auch ein paar eigene Funktionalitäten. Nun kommt es ab und zu vor, dass unser Kunde zu seinen Kunden muss und dabei die Datenbank "mitnehmen" will, die sonst auf seinem Server liegt. Beim Kunden selbst hat er dabei keinen Zugriff auf sein Netzwerk, also keine Möglichkeit auf die verlinkten Daten zuzugreifen. Die Funktionalität der Datenbank soll aber erhalten bleiben. Jetzt ist die Frage ob das möglich ist, also das man sagt, o.k., wenn ich die Datenbank auf einen Rechner repliziere, dann werden die gelinkten Dokumente gleichzeitig mit kopiert und auf dem lokalen System gespeichert. Meiner Meinung nach wäre es sinnvoller zu sagen, dass die Links dann eben inaktiv sind und er in der Zeit keinen Zugriff auf die verlinkten Daten hat, aber meine Frage ist halt, ob es prinzipiell möglich wäre die Links, die in der Datenbank stehen dann irgendwie "auszuwerten" und die echten Daten hinter den Links mit auf dem lokalen System zu speichern.
-
Erstmal ist zu sagen das es dem RDBMS egal ist was da als Text steht.
Der Client lädt den Text (link) und holt sich das Document und nicht das RDBMS.Wenn du es bei Replikation möchtest dann musst du die Document in ein BLOB bringen. Dadurch kann er die Docs (kommen nun als BIN-Daten aus der DB) auch mitnehmen.
Leider hast Du ja nur einen MSSQL 2000. In MSSQL 2008 ist das mit Filestream sehr gut gelöst.
-
Jetzt ist die Frage ob das möglich ist, also das man sagt, o.k., wenn ich die Datenbank auf einen Rechner repliziere, dann werden die gelinkten Dokumente gleichzeitig mit kopiert und auf dem lokalen System gespeichert.
Mal abgesehen von der BLOB-Lösung (weil die DB dadurch oft unwartbar gross wird) und der Filestream-Lösung (weils fast keine DB-Server gibt die sowas brauchbar implementieren)...
Klar ist das möglich, nur werdet ihr euch das selbst programmieren müssen.
Je weniger Spalten in der Datenbank das betrifft (idealerweise nur eine Spalte in einer Tabelle), desto einfacher.
Und je mehr man an der bestehenden Datenbank-Struktur ändern kann, desto einfacher.
-
hustbaer schrieb:
und der Filestream-Lösung (weils fast keine DB-Server gibt die sowas brauchbar implementieren)...
Wie kommt du darauf?
In MSSQL 2008 ist das implementiert. Sogar Replikation, Backup und Recovery (Backup Exec 12.5) funktionieren damit perfekt.
-
MSSQL 2008 ... und welche Server noch?
Ich hab ja geschrieben fast keine. Im Sinn von mehr als keine, aber viel viel weniger als viele.
Ich kenne kein anderes SQL basiertes (R)DBMS welches es noch kann.
"SQL basiert" hätte ich noch dazuschreiben sollen. (Ich kenne zwar auch kein nicht-SQL-basiertes DBMS welches das gut löst, allerdings kenne ich auch nicht wirklich viele nicht-SQL-basierte DBMS', also kann ich da nichts 'zu sagen.)
-
DIes ist ein ein Feature indem MS ein Alleinstellungsmerkmal hat.
Es reicht doch wenn es MSSQL 2008 in jeder Version unterstützt.
Dies reicht für Server als auch Desktop.
Ich möchte dieses Feature nicht mehr wegdenken denn die DB bleibt klein und z.B. Bilder sind immer gesichert ohne Freigaben etc. einzurichten.
Bei dir hört sich das an an als wäre es ein Feature welches die Welt nicht braucht und nur weil es dies bei MS gibt ist MSSQL böse.
Kann mich auch irren und habe dich falsch verstanden.
-
Unix-Tom schrieb:
Bei dir hört sich das an an als wäre es ein Feature welches die Welt nicht braucht und nur weil es dies bei MS gibt ist MSSQL böse.
Kann mich auch irren und habe dich falsch verstanden.Da hast du mich gänzlich falsch verstanden. Ich meinte damit bloss, da der OP noch MSSQL 2000 verwendet, fällt es für ihn aus. Und für die meisten anderen Anwendungen auch, wenn man sich nicht frei eine neue DB aussuchen kann. So war das gemeint.
Dass es ein sehr nützliches Feature ist denke ich auch. Ich hätte MSSQL 2008 zwei Jahre früher brauchen können, dann würde ein File-Repository unserer Firma (mit ein paar TB) heute anders aussehen. Naja... vielleicht macht sich mal wer die mühe das zu portieren