Import von WebDB-Objekten in Nicht-(Web)DB

[arminho]

Ehrlich gesagt, kann ich seit geraumer Zeit die in dieser Diskussion angeführten Argumente nicht mehr nachvollziehen, weil ich sie einfach nicht verstehe und nicht mehr erkennen kann, wer was will, mit welchen Instrumenten und warum oder auch nicht.

Stimmt, kaum schaut man mal einen Tag nicht hier rein, sind schon wieder 20 neue Argumente aufgeführt. Aber du könntest auch deine eigene Meinung zum Thema darlegen, ohne auf die anderen Argumente einzugehen.

@GMT:
Selbst wenn man 200 Elemente auf einmal importieren will verstehe ich nicht, wieso das gegen eine Master-DB sprechen soll. Du gehörst vermutlich zu den Leuten, die einen guten Überblick darüber haben, welcher Spieler in welcher DB zu finden ist oder sein könnte. Vermutlich recherchierst du auch gerne. Ich denke aber, dass der Otto-Normal-DB-Ersteller keine Lust hat, erst mal zig DBs zu durchsuchen bis er seinen gewünschten Spieler findet. Und so eine Funktion (die von der Programmierung her recht umfangreich sein wird) sollte schon einen hohen Nutzungsgrad haben. Wenn aber ein DB-Ersteller keine Lust hat, sich durch 20 oder auch nur durch 5 DBs zu kämpfen, bis er einen einzigen Spieler gefunden hat, wird er die Funktion auch nicht nutzen. Und noch was: Wenn wir von einem Massenimport sprechen, müssten wir auch definieren, wie der aussehen soll (das ist jetzt völlig wertfrei gemeint), also anhand welcher Kriterien wähle ich eine größere Menge an Spielern aus. Da kommen auch wieder einige neue Masken ins Spiel. Wobei ich mich hier nicht gegen einen Massenimport aussprechen will, mir ist nur nicht klar, wie man den sinnvoll verwirklichen will.

@all:
Zur Master-DB, um Missverständnissen vorzubeugen: Ich rede hier nicht (mehr) davon, dass der Nutzer die Master-DB erst selbst zusammen stellen soll. Eine um die Spiele und die Kader abgespeckte Master-DB würde längst nicht so viele Ressourcen verbrauchen wie eine komplett zusammengefasste DB. Abgesehen davon ist es technisch gesehen schon ein Unterschied, ob ich eine DB zum Anzeigen öffne (hier kommt noch dazu, dass zum Beispiel alle Wappen eingelesen und im Hauptspeicher abgelegt werden) oder ob ich mit den entsprechenden Techniken die DB verlinke, was dann am sinnvollsten wiederum mit einer Master-DB zu erreichen ist. Da so eine Master-DB ja nur eindeutige IDs enthält, könnte man für sie auch teilweise WebDB-Funktionen freischalten (natürlich nur lesende), so dass die Objekte (lesend) aktualisiert werden könnten. Diese Leserechte könnten dann auf die Master-DB eingeschränkt werden, wir reden hier also zwangsläufig von einer fest zu definierenden DB.
Da ich Kees Recht gebe, dass wir uns hier ein bisschen im Kreis drehen. Lege ich mich in diesem Punkt jetzt fest.

@tanne:
Dubletten-Abgleiche sind ein weites Feld. Wir müssen zwei Dinge unterscheiden:
1.) Der Abgleich anhand eines festen Kriteriums, hier die Objekt-ID.
2.) Der Abgleich anhand "weicher" Kriterien wie Name, Geburtsdatum etc.
Der 2. Fall benötigt spezielle Software, die darauf ausgerichtet ist mit Ähnlichkeiten zu arbeiten oder ein geschultes Auge in der manuellen Bearbeitung wie GMT schrieb. DFS kann den Dublettenabgleich nicht automatisch durchführen und wird es auch zukünftig nicht können. Selbst wenn ein Programm dazwischengeschaltet wäre, das mit Ähnlichkeiten umgehen kann (was dann ggf. auch eine Lizenz- und damit Kostenfrage wäre), müsste der einzelne DB-Ersteller trotzdem manuell entscheiden, was letztlich eine Dublette ist, und was nicht.