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

[scharfschwerdt]

Haben andere User des Forums keine Meinung zu dem Thema oder den Daten, die gebraucht werden?

Aber hallo! ^-^ Und nicht nur deswegen:

Ich schweige völlig von unterklassigen Deutschland-DB, die auch der Einheitlichkeit halber Mannschaften, Stadien und Personen aus "höherklassigen" DB übernehmen könnten. Bei Abstieg eines Teams "aus einer (Web)DB" in eine "Nicht-(Web)DB" jedes Jahr aufs Neue

Auch Spieler in meinen "Grüne Insel"-DBs sind durchaus betroffen, sowie U19-EM Teilnehmer (häufig bereits Stammspieler in europäischen Spitzenclubs) und U17-EM Teilnehmer (zumindest als Ersatzspieler) sowie Stadien dürften betroffen sein.

Für jede Möglichkeit einer Vereinheitlichung hier wäre ich dankbar - wenn ich auch sicher nicht alle sofort unreflektiert übernehmen würde, ich erinnere hier an die Benamsungsdiskussionen. Die SG Wattenscheid 09 z. B. hat eine rege Umbenennungsgeschichte, die ich in meinen Westfalen-DBs eingearbeitet habe, die aber teilweise nicht in höherklassigen DBs (ab Oberliga aufwärts) umgesetzt wurde. Daher würde ich auch einer selektiven Übernahme von Daten gegenüber einer Massenübernahme den Vorzug geben.

Mfg Michael

[GMT]

Um diesen Zweig der Diskussion auch noch zu füttern:

Ein automatisches Überschreiben interner Daten gibt es nicht und wird es wohl auch nie geben. Ein Dublettenabgleich ist immer eine bewußte Entscheidung. (Die ich auch ohne hinzuschauen treffen kann - den Warnhinweis einfach jedes Mal bestätigen ohne Nachzudenken ... ist dann aber nicht mehr die Schuld des Programmierers, wenn eigene Informationen verlorengehen.)

Importiere die SG Wattenscheid 09 einmal mit Volkers ID/GID, übernimm in diesen Datensatz alle Änderungen, die Du so möchtest und lösche dann die lokale Dublette.

Damit hast Du den Verein so wie Du ihn möchtest in der DB.

Nachteil: Du darfst nie mehr einen wie auch immer gearteten automatischen Aktualisierungsprozeß auf alle Mannschaften loslassen.


(Web)DB-Ersteller untereinander informieren in einem solchen Fall den "Zuständigen" (steht in der Verwaltungsfunktion neben der ID) und bitten ihn um das Anpassen des originalen Datensatzes.

Meine Frage ging eher dahin, welche Objekte dann mit einem Datensatz "mitgezogen" würden - Titel ohne Mannschaft gibt es nicht, also müßten alle "Titel-Mannschaften" eines Spielers automatisch mitkommen. Das geschieht quasi unbemerkt und kann zu Dubletten an anderer Stelle führen.
Beispiel:
Ich habe persönlich, sozusagen eigenhändig, noch nie eine japanische Mannschaft in meiner RUS-DB angelegt. Habe aber 6 solche Teams in der DB.
Wie die da wohl hineingekommen sind?  :

[jetset]

Auch Spieler in meinen "Grüne Insel"-DBs sind durchaus betroffen, sowie U19-EM Teilnehmer (häufig bereits Stammspieler in europäischen Spitzenclubs) und U17-EM Teilnehmer (zumindest als Ersatzspieler) sowie Stadien dürften betroffen sein.

Für jede Möglichkeit einer Vereinheitlichung hier wäre ich dankbar - wenn ich auch sicher nicht alle sofort unreflektiert übernehmen würde, ich erinnere hier an die Benamsungsdiskussionen. Die SG Wattenscheid 09 z. B. hat eine rege Umbenennungsgeschichte, die ich in meinen Westfalen-DBs eingearbeitet habe, die aber teilweise nicht in höherklassigen DBs (ab Oberliga aufwärts) umgesetzt wurde. Daher würde ich auch einer selektiven Übernahme von Daten gegenüber einer Massenübernahme den Vorzug geben.

Mfg Michael

Das spricht doch von einer Vereinheitlichung der Daten und Einzelabfrage in einem Import. Natürlich kann der Import nur vorhandene Daten übernehmen. Wenn man Diskrepanzen zwischen Nicht-WEB-DB und WEB-DB findet, sollte man sich, wie GMT gesagt hat, sich mit dem entsprechenden Erfasser der Daten für die WEB-DB auseinander setzen.

Für mich heißt dies, dass die verschiedenen DB Ersteller engeren Kontakt miteinander pflegen. Zur Kommunikation mit den einzelnen Personen haben wir hier im Forum ja genügend Boards.

jetset

[Kees]

Haben andere User des Forums keine Meinung zu dem Thema oder den Daten, die gebraucht werden?

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.

Gruß aus dem Teutoburger Wald

[Dieter]

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.

Bin ich anscheinend mit meinem Nix Verstehen doch nicht alleine.
Ich lese hier zwar immer mit, aber........ ???

[GMT]

Da ich das nun schon zweimal getan habe - vielleicht faßt ja jetset mal seine derzeitige Sicht der Dinge zusammen? 

[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.

[GMT]

Nehmt es mir nicht übel, aber ich sehe keinen Sinn in einer Diskussion, die sich bereits um Detailfragen des WOHER (welche DB öffnet die Funktion) ausführlichst kümmert, bevor überhaupt klar ist, WAS importiert werden soll und WIE.


Da ich mich nicht dauernd wiederholen will und mir Neues nicht mehr einfällt - auch nicht zum WOHER - klinke ich mich hier aus.

[Axel04]

Da ich mit meiner realtiv weitläufigen und datenintensiven Europacup-DB ja grundsätzlich von dieser Import-Funktion profitieren würde, hier mal meine Meinung dazu:

Also offengestanden kann ich bei dem einige Seiten zuvor geschilderten Verfahren der Suche nach einer spezifischen ID eines Objektes (bei mir v.a. Spieler) aus einer wie auch immer gearteten anderen DB kaum Zeitersparniss erkennen. Ich habe mittlerweile einen eingeschliffenen Automatismus bei meiner Dateneingabe, bei dem prinzipiell mehrere relevante Datenseiten und Google geöffnet sind und ich mit wenigen Klicks alle verfügbaren Infos beisammen habe bzw. im Zweifel nochmal überprüfen kann (nach über 10.000 Spielern macht man das quasi im Schlaf). Das tippen kostet mich kaum Zeit und ich recherchiere offengestanden ohnehin sehr gerne. Ausserdem habe ich so die Möglichkeit zusätzliche Infos via Notiz in die DB einfließen zu lassen (Sterbedaten u.ä.) und noch einmal genau nach eventuellen Länderspieleinsätzen zu forschen. Ausserdem hat das seperate Eingeben der Daten im Gegensatz zum Import den Vorzug, dass quasi ein zusätzlicher Kontrollmechanismus besteht, denn Fehler macht jeder mal.
Einziger Vorteil wäre in dieser Hinsicht lediglich die Vereinheitlichung mit Objekten der Web-DB und das ich meine Daten nochmal mit denen anderer DBs abgleichen könnte. Allerdings muss ich zugeben, dass ich mich beispielsweise beim Kader des albanischen UI-Cup-Teilnehmers XY oder des aserbaidschanischen Meister YZ schwertun würde, herauszufiltern welche Spieler u.U. schon in der Web-DB zu finden sind und welche nicht. Und das für alle 15.000 Spieler nochmal einzeln zu prüfen wäre schon ein gewaltiger Aufwand.
Ich könnte mir vorstellen, dass dies bei vielen anderen DB-Erstellern, insbesondere solchen, die sich mit kleineren osteuropäischen Ligen befassen ähnlich aussieht.

Was mir im Sinne der Vereinheitlichung sinnvoller erscheint wäre, dass man Erstellern von Nicht-Web-DBs technisch ermöglicht, ihre Datenbanken komplett mit Web-DBs zusammenzufassen (Web-DB Ersteller können das ja bereits). Somit ließe sich mit überschaubarem Aufwand eine Sychronisation erreichen. Leider wäre damit nicht unbedingt die von vielen gewünschte Arbeitsersparniss bei der Eingabe zu erreichen.

[chrisi]

Ich lese und komme zwar mit, allerdings kann ich den Sinn hinter dem Vorschlag immer noch nicht erkennen. ???

Es geht darum, dass man gewisse Spieler nicht mehr selbst erstellen muss, da sie bereits von einem anderen DB-Ersteller erstellt wurden. Also quasi wie bei den (Web)DB-Erstellern. Wenn ich einen solchen Spieler bei mir in der DB haben will (aus welchen Gründen auch immer) soll ich ihn also zukünftig importieren können statt ihn neuzuerstellen. Dabei ist noch offen, ob mit oder ohne Titelhistorie.

Und dann? Was für einen Nutzen hätte das? Die paar Sekunden, die man durch das Importieren (statt Neueingeben) spart sind es doch wohl irgendwie nicht wert oder?

Oder habe ich irgendeinen Punkt übersehen? ??? :

[tanne]

Wenn es um den einzelnen Import einzelner Spieler (z.B.) geht, dann

- ist die Zeitersparnis gering oder ggf. auch negativ im Vergleich zu dem manuellen Abtippen aus einer anderen DB, vor allem dann, wenn nach dem Einzel-Import noch die erforderliche manuelle Dublettenbereinigung gemacht wird, um den ggf. schon vorhandenen Spieler gegen den neuen gleichen auszutauschen;

- bleibt als Vorteil nur noch die gemeinsame ID/GID übrig, die ohne Zugriff auf Aktualisierungen aus der WebDB nur die Nutzung von fremden MyMedia-Bildern ohne deren Anpassung via MMO bringt, wenn man die von irgendwem irgendwann irgendwie bekommt.

Mein Fazit: Diese Funktion ist weitgehend nutzlos und wird daher außer von DB-Erstellern mit hohem systematischen Interesse am sinnfreien ID/GID-Abgleich nicht verwendet werden.


Eine deutliche Zeitersparnis bringt z.B. der komplette Import mind. eines Kaders, wenn ein Spiel oder eine Mannschaft übernommen werden kann. Dann steht der einmaligen Auswahl vieler Spieler der vielfachen Eingabe der Spieler gegenüber. Diese Funktion würde beliegt werden und deren Entwicklung wäre nützlich.

Damit muss aber ein DB-interner Dublettenabgleich erfolgen. Ich meine jetzt nicht die schwierige Suche nach Objekt-Ähnlichkeiten bei vordergründig deutlichen Abweichungen, sondern um die bei solchen Importen wahrscheinlichste Form der 100%-Dublette (vielleicht ohne Nationalmannschaftskennzeichen oder ohne Geburtsdatum) mit gleichem Namen. Wenn ich 20 Spieler eines Kaders importiere, ist es sehr wahrscheinlich, dass einzelne (namensidentische) Spieler schon in der DB sind. Wenn ich den einfachen Dublettenabgleich vor dem Import manuell mache, geht auch die Zeitersparnis der Massen-Importfunktion gegen null. Das gleiche gilt beim manuellen Dublettenabgleich nach dem Import, wenn ich die Spieler einzeln wieder in der Dublettenmaske suchen muss. Also muss es eine Programmunterstützung für den Dublettenabgleich geben, z.B. in der Form, dass in der Dublettensuchfunktion auf ein neues Feld "zum nächsten importierten Spieler" geklickt werden kann. Wahrscheinlich steht unmittelbar davor oder danach die 100%-Dublette und die Bereinigung kann mit 6 Klicks erfolgen. Mit dem 7. Klick geht es zum nächsten importierten Spieler. Mit dem Dublettenabgleich wird auch das "Importkennzeichen" wieder gelöscht.

Mein Fazit: Ohne Massenimport und ohne eine Programmunterstützung für den Dublettenabgleich wäre eine solche Funktion nutzlos und würde nicht verwendet werden, es sei den ... (siehe oben).

Diese Funktion wäre nur dann erfolgreich, wenn sie zugleich Zeitersparnis und Informationsgewinn bringt.


Später zu klären ist - da gebe ich GMT Recht - woher die Importdaten kommen und was mit Titeln etc. passiert. Erst muss klar sein, ob die Importfunktion überhaupt Vorteile bringt, also was und wie importiert wird.

[tanne]

Wäre es denkbar, aus einer DB eine Datenquelle anzusprechen und dann eine Maske zu erhalten, die sowohl die Spielerliste (als Objektimportbeispiel) der Datenquelle (z. B. in grüner Farbe) als auch die Spielerliste der eigenen DB (z. B. in roter Farbe) anzeigt, sinnvollerweise mit jeweiligen Selektionsmöglichkeiten auf (Nationalität,) Mannschaft und Saison ?

Dann könnten folgende Funktionen klickbar möglich sein:
1. Spieler aus der Datenquelle in die eigene DB importieren
1a. Spieler aus der Datenquelle in die eigene DB importieren und bei Optionsauswahl dem Kader der selektierten Mannschaft in der selektierten Saison hinzufügen
2. Spieler der eigenen DB durch einen Spieler aus der Datenquelle ersetzen
2a. Spieler der eigenen DB durch einen Spieler aus der Datenquelle ersetzen und bei Optionsauswahl dem Kader der selektierten Mannschaft in der selektierten Saison hinzufügen

Das hätte den Vorteil, dass sowohl ein Einzelimport (bei Auswahl jeweils eines Spielers aus Datenquelle und eigener DB) als auch ein Massenimport eines Mannschafts-Saisonkaders (bei Auswahl beliebig vieler Spieler aus der Datenquelle) mit wenigen Klicks möglich wäre und beim Einzelimport mit geringem Aufwand auch ein Dublettenabgleich vollzogen werden könnte. Dann wäre ergänzend für den Massenimport noch ein Importkennzeichen für den nachgeschalteten Dublettenabgleich nötig (siehe vorheriger Beitrag).

[jetset]

Hallo zusammen,

da es hier doch zu einigen Irritation und Mißverständnisse gekommen ist, versuche ich hier mal eine Zusammenfassung aus meiner Sicht darstellen.

Hintergrund des Vorschlags:

Der Hintergrund meines Vorschlags war eigentlich der, das ich mich die Qualität der einzelnen Datenbanken ein wenig gestört hat. Einerseits haben wir ein Ranking für die Datenbanken und andererseits haben die Datenbanken unterschiedlichen Informationsgehalt bei gleichen Mannschaften, Spieler, Schiedsrichter und Stadien. Geschweige bei Mannschaften die Bezeichnung, Historie, Schreibweise der nicht so bekannten Spieler. Jeder DB Ersteller hat unterschiedliche Informationsquellen (Fußball.de, Fußballdaten.de) und bei manchen Quellen wissen wir auch, dass die Richtigkeit der Informationen zu wünschen übrig läßt.

Dadurch kam mir die Idee, dass man die einzelnen Datenbanken durch einen Import der Objekte aus der WebDB aktualisieren, vereinheitlichen und somit die Qualität der einzelnen Datenbanken steigern kann. Als schöner Nebeneffekt kann es passieren, dass man im Idealfall ein Objekt selbst nicht mehr anlegen braucht.


Methoden des Imports:

Objekte für den Import:    Mannschaften, Spieler, Schiedsrichter, Stadien
                                    Kader für Pokal DBs (muß noch diskutiert werden)
                                    Titelhistorie ist auch noch nicht ausdiskutiert

Art der Auswahl:            Massen- oder Einzelabfrage
                                    Die Tendenz zielt auf eine Einzelabfrage aus, aber letztendlich
                                    wurde diese Frage auch noch nicht abschließend geklärt.

Quelle für den Import:    WebDB oder MasterDB
                                  Hier geht die Tendenz eindeutig zur MasterDB.

                                  Vorteile MasterDB:
                                  DB Ersteller brauchen nicht in verschiedenen Quellen suchen
                                  MasterDB wird zur Verfügung gestellt
                                  Aktualisierung 2 Mal jährlich von zentraler Stelle

                                Nachteil MasterDB:
                                eine weitere DB mit Pflegeaufwand

                                Vorteile WebDB:
                                schon vorhanden, kein Erstellungsaufwand
                                kein extra Pflegeaufwand
                                Zugriffsfunktionalität teilweise(?) schon vorhanden

                                Nachtteile WebDB:
                                hohes Trafficaufkommen

weitere Funktionalität:  Dublettenabgleich erweitern
                                automatische oder manuelle Änderung von Objektdaten in der
                                ZielDB
                                Auswahldialoge

Die rot makierten Punkte sollten erstmal abschließend geklärt werden.

jetset

[Kees]

Ich fange mit meinem Nichtverständnis ganz vorne an.

Was habe ich mir genau unter einer Master-DB vorzustellen? Was ist der Unterschied zur Web-DB, wer legt diese (Master-DB) an und pflegt sie bzw. ist verantwortlich für die Richtigkeit - oder vielleicht besser ausgedrückt - für die Allgemeingültigkeit (z.B. Schreibweisen, o.ä.) der Daten(sätze)?

Gruß aus dem Teutoburger Wald

[jetset]

Ich fange mit meinem Nichtverständnis ganz vorne an.

Was habe ich mir genau unter einer Master-DB vorzustellen? Was ist der Unterschied zur Web-DB, wer legt diese (Master-DB) an und pflegt sie bzw. ist verantwortlich für die Richtigkeit - oder vielleicht besser ausgedrückt - für die Allgemeingültigkeit (z.B. Schreibweisen, o.ä.) der Daten(sätze)?

Gruß aus dem Teutoburger Wald

Was ist eine MasterDB?            abgespeckte WebDB; Inhalt: Spieler, Mannschaft, Stadien, Schiris
Plege der DB?                          jetset

[arminho]

Ein automatischer Dublettenabgleich nur anhand des Namens wird schwierig. Beispiel aus der Slowakei-DB: Jan Kozak. Kommt zweimal vor. In der Slowakei wird gerne mit jun./sen. gearbeitet. Diese Information wird aber in der WebDB nicht geführt. Hätte ich einen Jan Kozak in der DB und würde den zweiten hinzuimportieren, würde der erste gelöscht, jedenfalls wenn ich das Geburtsdatum weglasse.

Zum Einzel/Massenimport und der Frage des WIE:

Die Frage ist, ob ein Einzelimport nicht doch ausreicht. Im Prinzip gibt es ja zwei Status (am Beispiel Spieler):
1.) Ich will einen neuen Spieler anlegen, der noch nicht in meiner DB vorhanden ist.
2.) Ich will einen vorhandenen Spieler aktualisieren, so dass er u.a. eine WebDB-ID bekommt.

Im ersten Fall brauche ich keinen Dublettenabgleich, denn der Spieler ist in meiner DB ja nicht vorhanden. Ich suche also nur und kopiere ihn ggf. in meine DB.

Im zweiten Fall könnte ich auch den Spieler in der Spielerverwaltung anklicken und brauche da eigentlich nur einen Button "abgleichen". Mit den vorhandenen Informationen aus dem Spieler-Eintrag könnte DFS dann in der Master-DB suchen gehen und eine Ergebnisliste bringen, in der man einen Spieler markieren und per Button übernehmen kann (dieser ersetzt dann den eigenen). Auch hier ist keine Dublettenabgleichfunktion notwendig.

So würde auch die Suchmaske entfallen. Für Fall 1 könnte man die vorhandenen leeren Felder der Objektänderung benutzen (Button "Neue Person anlegen/suchen).

[GMT]

An dieser Stelle habe ich am 22.12. die laufende Diskussion abgebrochen und "aus der Öffentlichkeit genommen". Die ging dann kurzfristig unter den (Web)DB-Erstellern weiter.

Damit das hier nicht einschläft, wieder ein Anstoß:

Die Diskussion habe ich dann nur mal nebenbei gelesen. Aber da geht es mit Ideen, Fragen und Antworten so hin und her, dass man nicht mal eben versteht, was wirklich gewünscht ist. Ehrlich gesagt, habe ich das bisher immer noch nicht verstanden. Auch wenn mehrfach nach eine klaren Aussage aufgefordert wurde.
...
Ich dachte zu Beginn der öffentlichen Diskussion, dass der Wunsch lediglich darin bestehe, einzelne Objekte abzugleichen. Mit dem Hintergrund, dass
1. ID/GID für MyMedia einheitlich werden und
2. die "Stamm-"daten der Objekte übernommen werden können.
...
Mit Stammdaten meine ich z.B. Namen, Geburtsdaten usw. von Spieler. Aber nicht das Nachziehen von Titeln usw., was ja oben schon als aufwändig und tricky angemerkt wurde.
...

Es sollte also hier bitte klarwerden, was eigentlich wirklich gewünscht ist und wozu.

Und um nicht wieder zu weit vom Kern wegzulaufen, versuche ich das mal zu moderieren. Ich meine direkt die Diskussion zu führen. *)

Zunächst möchte ich Euch bitten, ausschließlich die folgende Frage zu beantworten:

Wozu wird ein solcher Import eigentlich benötigt?

Was also wird bezweckt, welcher Vorteil soll daraus entstehen, welche Vereinfachungen sollen sich ergeben - all' solche Fragen.

Fragen über das Wie, in welcher Situation der DB-Erstellung und -Pflege, über die konkrete Quelle (Einzel-DB/Master-DB) oder dergleichen bitte jetzt nicht erörtern und auch nicht andeuten, die kommen später dran.

*) Sollte das ganz und gar nicht gewünscht werden oder sollte das jemand anders machen - ich persönlich muß das nicht haben.
Ich finde nur die Idee zu interessant, um sie absterben zu lassen.

[tanne]

Für mich wäre folgendes Ziel anzustreben:

"Massen"-import von Spielern mit maschinell unterstützem Dublettenabgleich (näher beschrieben in den Beiträgen #60 und #61).



EDIT GMT
Zur optischen Kennzeichnung, daß das im Moment nicht dem "roten Faden" folgt, ändere ich ab sofort diese Beiträge farblich.

[GMT]

Wozu? Was willst Du erreichen?

Dein Beitrag ist genau einer von denen, die wir momentan nicht brauchen - erstmal muß Klarheit über den Zweck herrschen.

Oder gehst Du in den Baumarkt und kaufst irgendeinen Bohrer, ohne zu wissen, in welchem Material das Loch benötigt wird?

[Hermi]

ich habe die ganze Diskuusion in diesem Thread nicht ausreichend verfolgt, da ich nicht unbedingt Kenntnisse über die Tiefen vom DFS Programm habe und wie weit einiges machbar ist.

Eine Master DB würde ich aber begrüßen (Spieler, Trainer, Schiri, Mannschaften und Stadien) denn das würde allen helfen, die eine DB erstellen, wir anderen hätten auch etwas davon, denn dann wären alle Daten identisch und es gäbe sicher weniger Fehler (wenn sich der DB Ersteller daran hält.

Hierzu eine Frage, in meiner DB habe ich einige Spieler usw. die ich selbst angelegt habe,
1. kann ich denn Spieler usw. aus anderen DB übernehmen, wie?
2. kann ich bei meinen Spielern die ich selbst angelegt habe die richtige GID usw, hinzufügen?
(andernfalls müße ich diesen löschen, neu anlegen (mit GID) und in allen Aufstellungen wieder hinzufügen, das wäre mir für meine jetzige DB zu viel)

[jetset]

1. kann ich denn Spieler usw. aus anderen DB übernehmen, wie?
2. kann ich bei meinen Spielern die ich selbst angelegt habe die richtige GID usw, hinzufügen?
(andernfalls müße ich diesen löschen, neu anlegen (mit GID) und in allen Aufstellungen wieder hinzufügen, das wäre mir für meine jetzige DB zu viel)

Genau darum geht es in meinem Vorschlag.


@all

Warum ein Import?

Der Gedanke des Imports kam mir, nachdem ich ein Ligasystem für Deutschland in den obersten 4 Ebenen aufgebaut habe. Mir fiel auf, das so einige Mannschaften (SG Wattenscheid) verschiedene Schreibweisen und GIDs besitzen.

Ich dachte mir ja das wäre doch was, wenn alle DBs eine einheitliche Schreibweise hätten.

Wie erreicht man so etwas?

Na klar, ich nehme mir jetzt aus einer DB die entsprechenden Daten raus und nutze diese Daten für meine DB, also ein Import.

Zweck:

einheitliche GIDs/IDs
einheitliche Benamung von Namen
einfaches Aktualisieren von Daten (Abtippen birgt eine Fehlerquelle)
schnell einen Grundstamm an Stammdaten (Spieler, Schiris, etc)

Ziel:

Qualitätssteigerung der einzelnen DBs
weniger Fehler in den DBs bei gleichen Daten (oder überall derselbe Fehler)

Das waren so meine Gedanken.
Beim Erstellen der hist. Regionalligen von 1963 bis 1974 bemerkte ich dann, dass so eine Importfunktion doch sehr wertvoll für eine DB-Erstellung sein kann, denn knapp 60% der Daten (Spieler, Schiris, Mannschaften, Stadien) sind schon in anderen DBs aus Deutschland vorhanden. Oder wenn jemand die persönlichen Erfolge eines Spieler nicht von Anfang an gepflegt hat, wird das Nachpflegen zur Qual.

Ein weiteres Ziel:

Verringerung des Aufwandes bei der Pflege der DB

In diesem Sinne
jetset

[GMT]

Um nochmal zu unterstreichen, worum es mir momentan geht:

In der Beschränkung oder auch in der Konzentration auf's Wesentliche erkennt man den Meister.
Beispiel: Volker wurde von den Beta-Testern auf eine Möglichkeit angesprochen, Spiele mit Aufstellungen usf. umorganisieren zu können. Nicht innerhalb einer Saison - das geht auch in der Saisonerstellung - sondern eben zur Umstrukturierung von DB. Pokale vor allem.
Das wäre für Volker programmtechnisch ein Theater ohne Ende geworden. Nachdem wir den Kern des Ganzen formuliert hatten fand sich die heutige Lösung: Man kann komplette Spieltage von einer Saison einer Liga in eine andere Saison einer anderen Liga verschieben.
Zusammen mit den schon vorhandenen Möglichkeiten der Saisonerstellung gab das eine ausreichend flexible Möglichkeit ohne daß Volker Kopfstände machen mußte.

Wir müssen uns hier, damit das Ganze nicht von vornherein zum Monstervorschlag wird, auf das Wesentliche konzentrieren.

Vorab muß auch klar sein:
Das Maximum wäre ein Vollzugriff für jeden auf die WebDB.
Und den wird es nicht geben.
Ebensowenig wie Massenexporte (bzw. Massenimporte).


Das Wesentliche ist, so verstehe ich jetset nun nicht zum ersten Mal, sind

• • einheitliche ID/GID
    
  • einheitliche Stammdaten - siehe das Volker-Zitat oben
    
  
  Aktualisieren der Daten ist schon wieder ein Folgeproblem.
  Und "schnell einen Grundstamm an Stammdaten" bekomme ich zum Start auch durch Hernehmen einer vorhandenen DB.
  
  Die persönlichen Erfolge von Spielern sind aus technischen Gründen auch ein Gedanke, in den wir uns nicht gleich zum Start auf Dauer verlieben sollten. Da gibt es eine Reihe von schon mal angedeuteten Fallstricken.
  
  
  Gibt es unter dem Gesichtspunkt der Beschränkung auf das Wesentliche sonst noch Ideen?

[Hermi]

• Gibt es unter dem Gesichtspunkt der Beschränkung auf das Wesentliche sonst noch Ideen?

Ja ich hätte noch eine, aber ob das geht weiß nicht.
Wenn ich nun in meiner DB einen selbst angelegten Spieler habe undd diesen gegen einen Spieler mit entsprechender GID austauschen möchte, wäre es schön, wenn das Programm dieses selbst machen könnte.
Also alten Spieler markieren, neuen Spieler markieren und das Programm tauscht diesen Spieler dann in sämtlichen allen Aufstellungen meiner DB aus.
Ist so etwas kompliziertes überhaupt möglich oder habe ich da eine blöde Idee.?

[Axel04]

• [quote author=GMT link=topic=18668.msg131439#msg131439 date=1230493782]
  Gibt es unter dem Gesichtspunkt der Beschränkung auf das Wesentliche sonst noch Ideen?

Ja ich hätte noch eine, aber ob das geht weiß nicht.
Wenn ich nun in meiner DB einen selbst angelegten Spieler habe undd diesen gegen einen Spieler mit entsprechender GID austauschen möchte, wäre es schön, wenn das Programm dieses selbst machen könnte.
Also alten Spieler markieren, neuen Spieler markieren und das Programm tauscht diesen Spieler dann in sämtlichen allen Aufstellungen meiner DB aus.
Ist so etwas kompliziertes überhaupt möglich oder habe ich da eine blöde Idee.?
[/quote]

Ich würde sagen in diesem Fall könntest du auch ebensogut den Dublettenabgleich zu Rate ziehen, der im Programm bereits vorhanden ist.

Ansonsten denke ich in der Tat, dass die Einheitlichkeit von ID/GID sowie der Stammdaten die wesentlichen erstrebenswerten Vorteile dieser Funktion sind. Weitere würden mir nicht einfallen.
Dahingehend möchte ich aber mal zur Diskussion stellen, wie viele DB-Ersteller diese Funktion dann überhaupt nutzen würden. Das Problem, welches ich bei der ganzen Operation sehe, ist dass die DB-Ersteller ja erstmal im Blick haben müssten, welche Spieler ihrer Datenbank es bereits im öffentlichen ID-Bereich gibt und welche nicht (und somit welche sie importieren müssten und welche nicht). Da dies wohl kaum jemand lückenlos im Kopf hat, wird es aber nötig den gesamten Datenbestand einzeln auf solche Objekte abzusuchen. Und da stellt sich für viele Ersteller wahrscheinlich die Aufwand-Nutzen-Frage.

[Hermi]

Ich würde sagen in diesem Fall könntest du auch ebensogut den Dublettenabgleich zu Rate ziehen, der im Programm bereits vorhanden ist.

Dadurch würde aber nur der "doppelte" Spieler gelöscht, (zuvor muß ich diesen aber manuell aus allen Aufstellungen nehmen, und den neuen Spieler wieder manuell einfügen)
aber nicht gleichzeitig in den Aufstellungen ausgetauscht was ich meinte, aber das wird wohl nicht möglich sein, meine Idee ist sicher zu kompliziert.

[Axel04]

[quote author=Axel04 link=topic=18668.msg131485#msg131485 date=1230558996]
Ich würde sagen in diesem Fall könntest du auch ebensogut den Dublettenabgleich zu Rate ziehen, der im Programm bereits vorhanden ist.

Dadurch würde aber nur der "doppelte" Spieler gelöscht, (zuvor muß ich diesen aber manuell aus allen Aufstellungen nehmen, und den neuen Spieler wieder manuell einfügen)
aber nicht gleichzeitig in den Aufstellungen ausgetauscht was ich meinte, aber das wird wohl nicht möglich sein, meine Idee ist sicher zu kompliziert.
[/quote]

Eigentlich wird der Spieler nach dem Dubelettenabgleich auch in allen Kadern und Aufstellungen durch den Neuen ersetzt. Du brauchst also nichts zu machen ausser dieser einen Operation.

[GMT]

Hermi, Axel04 hat recht.

Der Dublettenabgleich macht genau das, was Du wohl nicht für möglich hältst.

Allerdings schrieb ich weiter vorn schon, daß ein direkter Abgleich für mich bei einem Einzelimport dazugehört. Also benötigten Spieler importieren, existierenden angeben und Dublette löschen.

[champion]

[quote author=Axel04 link=topic=18668.msg131485#msg131485 date=1230558996]
Ich würde sagen in diesem Fall könntest du auch ebensogut den Dublettenabgleich zu Rate ziehen, der im Programm bereits vorhanden ist.

Dadurch würde aber nur der "doppelte" Spieler gelöscht, (zuvor muß ich diesen aber manuell aus allen Aufstellungen nehmen, und den neuen Spieler wieder manuell einfügen)
aber nicht gleichzeitig in den Aufstellungen ausgetauscht was ich meinte, aber das wird wohl nicht möglich sein, meine Idee ist sicher zu kompliziert.
[/quote]Das wird aber beim Dublettenabgleich gemacht. :-[

[bignike]

Der Dublettenabgleich unter

Recherche ->  Dubletten suche - > Spieler/Trainer


Spieler B -> Spieler A


dh alle Informationen zum Spieler B, werden dem Spieler A zu geschrieben, du musst nicht den gelöschten Spieler aus jeder Aufstellung suchen und eintragen sondern das geschieht automatisch.

[Hermi]

Hallo Axel04, Champion, GMT, Bignike
Toll, schon wieder was gelernt, man lernt halt nie aus.
Das ist ja eine prima Funktion O0

[Plotsch]

Ich denke die Kernfrage von GMT "Wozu wird ein solcher Import eigentlich benötigt?"

hat jetset im Wesentlichen beantwortet:

"einheitliche GIDs/IDs
einheitliche Benamung von Namen
einfaches Aktualisieren von Daten (Abtippen birgt eine Fehlerquelle)
schnell einen Grundstamm an Stammdaten (Spieler, Schiris, etc)"

und
"Qualitätssteigerung der einzelnen DBs
weniger Fehler in den DBs bei gleichen Daten (oder überall derselbe Fehler)"


Das sehe ich ähnlich wie jetset.

Allerdings gibt es ein Problem, dass  bisher nicht diskutiert wurde. In der Debatte wurde bisher immer davon ausgegangen, dass die meisten Daten im Moment als Stammdatensatz in der WebDB vorhanden sind. Das mag für viele europäische Vereine gelten (für außereuropäische Vereine schon mal nicht), für eine Mende Spieler gilt es aber mit Sicherheit nicht.

Es muss also eine Lösung her, die den Import von Stammdaten, von jeder DB in jede DB ermöglicht. So muss ich Stammdaten aus der Mex-DB in meine Arg-DB genauso leicht importieren können wie aus den Web-DB's.
Nur dann macht eine solche Lösung für alle DB-Ersteller maßgeblich Sinn und erfüllt die oben aufgeführten Voteile, zumindest in meinen Augen.
 

MfG

Plotsch

[GMT]

Es muss also eine Lösung her, die den Import von Stammdaten, von jeder DB in jede DB ermöglicht. So muss ich Stammdaten aus der Mex-DB in meine Arg-DB genauso leicht importieren können wie aus den Web-DB's.
Nur dann macht eine solche Lösung für alle DB-Ersteller maßgeblich Sinn und erfüllt die oben aufgeführten Voteile, zumindest in meinen Augen.

So sehr ich Dich verstehe - ich fürchte, daß das über das Ziel hinausschießt.

Zunächst mal gibt es in MEX und ARG sehr viele Überschneidungen von ID.
ID 100.000.000 - die Start-ID in allen Nicht-(Web)DB beschreibt in beiden DB jeweils unterschiedliche Objekte (Spieler, Mannschaften ...).
Das ist aber nur die Hälfte des technischen Problems.

Die in der WebDB und den einzelnen (Web)DB vorhandenen Daten sind untereinander abgestimmt. Mit klarer Zuständigkeit für das jeweilige Objekt.
Ohne eine Online-Datenbasis - die WebDB eben - läßt sich weder die Zuständigkeit noch die Aktualität der Daten sicher in Echtzeit sicherstellen.
Was meine ich damit?
Irgendwann stellst Du fest, daß Spieler X aus MEX (mit einer MEX-ID) in Deiner DB schon vorhanden ist - mit einer anderen ID, der ARG-ID. Du importierst den Spieler jetzt also offline aus der MEX-DB (das eben geschilderte ID-Überschneidungs-Problem lassen wir jetzt mal völlig außen vor) in Deine DB, um einen Dublettenabgleich zu machen.
Das geht nur, indem Du entweder beathmath veranlaßt, nun seinerseits "Deinen" Spieler mit der ARG-DB in seine DB zu importieren und dort "seinen" als Dublette zu löschen - klingt albern, nicht wahr? - oder das in der Gegenrichtung stillschweigend in Deiner DB tust, also "Deinen" Spieler als Dublette löschst. Übrig bleibt in Deiner DB der Spieler mit der MEX-ID. Jetzt mußt Du ganz schnell ein Update machen, damit alle die aktuelle ARG-DB haben können.

Nach Deinem Dublettenkillen, aber bevor er die aktualisierte ARG-DB heruntergeladen hat, stellt FCB_Fan fest, daß Dein ARG-ID-Spieler auch in seiner DB vorhanden ist. Und importiert jetzt Deinen Spieler in seine USA-DB. Seine lokale ARG-DB "weiß" von Deinem Dublettenabgleich noch nichts. Also gibt es den Spieler weiterhin mit mehreren ID in den verschiedenen Datenbanken.

Konnte ich mich verständlich machen?


Fazit:
Es gibt zwei technische Gründe, die eine gemeinsame Datenbasis außerhalb der WebDB bzw. den einzelnen (Web)DB unmöglich machen.

[Gabor70]

Wenn ich jetset richtig verstanden habe, geht es ihm in erster Linie um die GID's/ID's der Mannschaften bezüglich des Ligasystems. Alles andere schweift hier in meinen Augen zu weit von der Ausgangsfrage ab.
Und eine Importfunktion nur für Mannschaften, sollte machbar sein.

Ich habe mich mit einigen Funktionen oder Statistiken im Studio noch nicht so ausgiebig beschäftigt, also Berichtigt mich bitte wenn ich Falsch liege, aber ich glaube die Funktion des Ligasystems ist die einzige Funktion im Studio in der man mehrere DB's miteinander "verknüpfen" kann. Und da in der Ansicht auch bis Dato "nur" Mannschaften zu sehen sind, braucht man sich über ID's und Schreibweisen einzelner Spieler oder sonstiges, nicht weiter Gedanken machen.

Man könnte diese Importfunktion als Einzelimport programmieren ohne mitnahme externer Daten, wie z.B. Meisterschaften, Stadien usw.

[GMT]

Du hast recht - die Mannschaften waren der Ausgangspunkt.

Sofort aber hat jetset selbst den Vorschlag auf die anderen denkbaren Objekte erweitert. Daher schweifen wir vom Thema nicht ab, wenn wir uns allgemein mit dem Import dieser Objekte beschäftigen.
Schlußendlich ist der Mechanismus bei allen derselbe.
Womit eine Beschränkung auf Mannschaften nicht nur wenig sinnvoll wäre, sondern bald durch Folgewünsche "auch für ... bitte" aufgehoben würde.

[jetset]

Es muss also eine Lösung her, die den Import von Stammdaten, von jeder DB in jede DB ermöglicht. So muss ich Stammdaten aus der Mex-DB in meine Arg-DB genauso leicht importieren können wie aus den Web-DB's.
Nur dann macht eine solche Lösung für alle DB-Ersteller maßgeblich Sinn und erfüllt die oben aufgeführten Voteile, zumindest in meinen Augen.

Wenn ich meinen Gedanken weiter führe, dann komme ich zu deinem Punkt Plotsch. Die Vorraussetzung für den Import aus einer beliebigen DB kann oder sollte dann nur durchgeführt werden, wenn alle DBs die gleiche Datengrundlage haben.


Da jetzt der Sinn und Zweck allen soweit klar ist, sollte wir uns überlegen, wo die Daten herkommen.

Mein ursprünglicher Vorschlag war ja die DFS DB, aber schnell habe ich eingesehen, das diese DB nicht ausreichend genug ist (nichts gegen Volker und Kees), sondern die WebDB als Grundlage dienen könnte. Kaum war der Gedanke ausgesprochen kamen schon die Argumente gegen die WebDB, die auch verständlich sind.Der größte Nachteil liegt im Traffic-Aufkommen, wenn viele Objekte von mehreren DB-Erstellern geladen werden.

Der nächste Vorschlag war der, das wir die WebDBs in einer sogenannten "MasterDB" zusammenfassen und 2 Mal jährlich eine Aktualiesierung durchführen. Inhalt dieser MasterDB sind nur die Stammdaten der Spieler, Mannschaften, Schiedsrichter, Stadien. Aus meiner Sicht haben wir auch hier einige Probleme:

Ich sehe hier den Aktualisierungsprozeß als Problem, denn auch hier brauchen wir dann Funktionalität, um die neuen Objekte in die "MasterDB" zu bekommen oder soll bei neuen Objekten jedesmal die WebDBs neu zusammengeführt werden und ständig immer wieder die Saisons gelöscht werden? In diesem Fall drehen wir uns dann immer wieder im Kreis.

Meiner Meinung nach sollte derjenige (jetset) bei der Erstellung oder Pflege der MasterDB über einen Dateiauswahl Dialog auf die WebDB zugreifen können. Dateiauswahldialog in der Importfunktion dafür, das entweder die MasterDB oder zur Pflege der MasterDB auf die WebDB zugegriffen werden kann.

Ich stell mir den Ablauf folgendermaßen vor:

• Erstellen der MasterDB durch Zusammenführen der einzelnen WebDBs
  
• MasterDB zum Download zur Verfügung stellen
  

Jetzt stelle ich mir die Frage, ob diese MasterDB einen Online-Zugriff hat oder ob der DB-Ersteller die komplette MasterDB lokal speichern soll und dann seinen Abgleich durchführen soll?

Soweit erstmal aus meiner Sicht und in diesem Sinne
jetset

[Gabor70]

Was meine ich damit?
Irgendwann stellst Du fest, daß Spieler X aus MEX (mit einer MEX-ID) in Deiner DB schon vorhanden ist - mit einer anderen ID, der ARG-ID. Du importierst den Spieler jetzt also offline aus der MEX-DB (das eben geschilderte ID-Überschneidungs-Problem lassen wir jetzt mal völlig außen vor) in Deine DB, um einen Dublettenabgleich zu machen.
Das geht nur, indem Du entweder beathmath veranlaßt, nun seinerseits "Deinen" Spieler mit der ARG-DB in seine DB zu importieren und dort "seinen" als Dublette zu löschen - klingt albern, nicht wahr? - oder das in der Gegenrichtung stillschweigend in Deiner DB tust, also "Deinen" Spieler als Dublette löschst. Übrig bleibt in Deiner DB der Spieler mit der MEX-ID. Jetzt mußt Du ganz schnell ein Update machen, damit alle die aktuelle ARG-DB haben können.

Nach Deinem Dublettenkillen, aber bevor er die aktualisierte ARG-DB heruntergeladen hat, stellt FCB_Fan fest, daß Dein ARG-ID-Spieler auch in seiner DB vorhanden ist. Und importiert jetzt Deinen Spieler in seine USA-DB. Seine lokale ARG-DB "weiß" von Deinem Dublettenabgleich noch nichts. Also gibt es den Spieler weiterhin mit mehreren ID in den verschiedenen Datenbanken.

Konnte ich mich verständlich machen?

Absolut!

Aber würde das nicht nur in der Übergangszeit bestehen?
Wenn es eine Master-DB geben würde und jeder sich an dieser ausrichten würde, hätte man dieses Problem nach spätestens einem Jahr nicht mehr. Es besteht somit nur die Frage, ob jeder dazu bereit wäre, seine DB bei entsprechender Möglichkeit umzustellen, sprich Daten zu ersetzen. Was natürlich bei der einen oder anderen DB ein haufen Arbeit wäre.

[jetset]

Aber würde das nicht nur in der Übergangszeit bestehen?

Wenn es eine Master-DB geben würde und jeder sich an dieser ausrichten würde, hätte man dieses Problem nach spätestens einem Jahr nicht mehr. Es besteht somit nur die Frage, ob jeder dazu bereit wäre, seine DB bei entsprechender Möglichkeit umzustellen, sprich Daten zu ersetzen. Was natürlich bei der einen oder anderen DB ein haufen Arbeit wäre.

Ja, das stimmt Gabor70.

Ein Haufen Arbeit ist es dann. Da spielt natürlich auch die Auffassung eines jeden Einzelnen mit, in welcher Qualität er seine DB der Allgemeinheit zur Verfügung stellen will. Ich persönlich würde den Aufwand für meine DBs in Kauf nehmen.

[GMT]

Wir sind offensichtlich an einem Punkt angekommen, wo Klarheit besteht, was gewollt wird.

Ich formuliere das nicht zum ersten Mal, siehe oben:

Das Wesentliche ist, so verstehe ich jetset nun nicht zum ersten Mal, sind

• einheitliche ID/GID
  
• einheitliche Stammdaten - siehe das Volker-Zitat oben
  

Aktualisieren der Daten ist schon wieder ein Folgeproblem.
Und "schnell einen Grundstamm an Stammdaten" bekomme ich zum Start auch durch Hernehmen einer vorhandenen DB.

So daß wir jetzt zum nächsten Problem übergegangen sind: Woher konkret sollen die Daten kommen? Und in welcher Form?

Absolut!

Aber würde das nicht nur in der Übergangszeit bestehen?
Wenn es eine Master-DB geben würde und jeder sich an dieser ausrichten würde, hätte man dieses Problem nach spätestens einem Jahr nicht mehr. Es besteht somit nur die Frage, ob jeder dazu bereit wäre, seine DB bei entsprechender Möglichkeit umzustellen, sprich Daten zu ersetzen. Was natürlich bei der einen oder anderen DB ein haufen Arbeit wäre.

Nein, das Problem wird ewig bestehen. Ewig für alle die Objekte, die nicht in die WebDB geschrieben werden.

Die Master-DB ist gedacht als ein Mittel, um WebDB-Objekte offline, also ohne WebDB-Zugriff in eine Nicht-(Web)DB zu übernehmen.
Die Master-DB ist mithin eine Einbahnstraße.
jetset oder beathmath oder Plotsch werden dort niemals einen eigenen Spieler hineinbekommen. Jedenfalls solange nicht, wie sie nicht (Web)DB-Ersteller werden sollten. Und dann bräuchten sie die Master-DB passiv (zum Herausziehen von Objekten) nicht mehr, sondern gehörten zum Kreis derer, die sie mit WebDB-Objekten füttern.

[jetset]

So, dann stelle ich mal ein paar Fragen.

Dient die WebDB nur für die Updates?

Wenn ja, dann wäre, vorrausgesetzt es existiert eine Master-DB, die WebDB eine Teilmenge der Master-DB. Richtig?

Dann haben wir also 2 DBs für 2 verschiedenen Funktionen. Richtig?
Meiner Meinung ist dann eine von diesen DBs, dann überflüssig, wenn die Master-DB die selben Beschränkungungen hat wie die WebDB.

Eine Master-DB macht doch nur dann Sinn, wenn alle DB-Ersteller einen Vollzugriff auf die Master-DB haben.

Meine Bedenken für das Öffnen der WebDB sind der Traffic, der erzeugt wird und das dann über kurz oder lang die Anforderung zum LU kommt, das ja in diesem Umfang nicht gewünscht wird. Also bleibt in meinen Augen nur der Zwischenschritt über eine Master-DB mit vollem Zugriff auf diese DB.

Bleibt auch noch die Frage, wenn eine Master-DB realisiert wird, ob es einen Online- oder Offline-Zugriff auf diese erfolgen soll?

jetset

[GMT]

Dient die WebDB nur für die Updates?

Nein, die WebDB dient als gemeinsame Online-Datensammlung für alle Objekte.

Jedes Objekt einer (Web)DB findest Du auch in der WebDB. Aber nicht umgekehrt.

Jede (Web)DB ist mithin - auf die Objekte bezogen - eine Teilmenge der WebDB.

Wenn ja, dann wäre, vorrausgesetzt es existiert eine Master-DB, die WebDB eine Teilmenge der Master-DB. Richtig?

Die WebDB kann keinesfalls eine Teilmenge einer Master-DB sein, sondern nur umgekehrt:
Eine Master-DB kann nur eine Teilmenge der WebDB sein.
Grund: Vor allem die ID-Problematik, die ich oben schon mal beschrieb.
Und noch einige andere technischen "Nebengeräusche".

Dann haben wir also 2 DBs für 2 verschiedenen Funktionen. Richtig?

Hätten wir, wenn es eine Master-DB gäbe.

Eine Master-DB, so wie sie von Gabor70 hier erstmals ins Spiel gebracht wurde, kann nur eine einzige Funktion haben: Alle Objekte aus der WebDB gesammelt in einer Datenbank anbieten, so daß man nicht mehr in verschiedenen (Web)DB suchen muß.

Sie kann von vornherein nur offline genutzt werden. Dort hat natürlich jeder Ersteller Vollzugriff - aber auch das altbekannte Problem, daß nicht mehrere Leute parallel an einer DB arbeiten können.

Meiner Meinung ist dann eine von diesen DBs, dann überflüssig, wenn die Master-DB die selben Beschränkungungen hat wie die WebDB.

Danke für diesen Satz!
Wir sind uns ja wohl einig, daß nicht die WebDB die überflüssige sein kann. 

Was ich von einer Offline-Master-DB halte, habe ich schon angedeutet:
Wer eine will, soll sie sich ruhig machen, soll sie von mir aus auch veröffentlichen, kann dafür sogar Platz auf dfs-datenbanken.ru bekommen - aber benötigt (im Sinne von: Ohne eine Master-DB ist alles von Dir ursprünglich Vorgeschlagene unmöglich bzw. wird sehr umständlich) wird sie keinesfalls.

Und ganz strenggenommen hast Du sie ja auch selbst schon in Deinem ersten Beitrag ausgeschlossen, denn: Eine Master-DB ist keine (Web)DB.
Du kannst mir ihr z.B. kein Live-Update der Ligen machen, die "in ihren Original-DB" LU-fähig sind.

Meine Bedenken für das Öffnen der WebDB sind der Traffic, der erzeugt wird und das dann über kurz oder lang die Anforderung zum LU kommt, das ja in diesem Umfang nicht gewünscht wird.

Meine - völlig unbedeutenden, ich heiße ja nicht Volker - Bedenken sind andere:
Die WebDB ist sozusagen das Herzstück des gemeinsamen Datenbestandes. Sie verlangt ein hohes Maß an Disziplin der schreibenden Nutzer, um sie nicht sinnlos werden zu lassen.
So muß ich zum Beispiel beim Anlegen eines neuen Spielers immer die WebDB darauf befragen, ob es den dort schon gibt - sonst lege ich ggf. eine Dublette an.

Daher ist Deine Formulierung

... LU ..., das ja in diesem Umfang nicht gewünscht wird.

völlig daneben.
Genauer: Dieser Gedanke ist nebensächlich.
Nicht der LU wird nur eingeschränkt gewünscht, sondern Schreibrechte für die WebDB werden sehr qualitäts- und sicherheitsbesorgt vergeben.

[GMT]

Der Klarheit, der besseren Lesbarkeit halber ein neuer Beitrag.


Da über den Zweck Einigkeit zu herrschen scheint, jetzt die Frage zum Wie - nicht zum Woher.
Bitte jetzt nicht Master-DB und dergleichen wieder aufwerfen, das kommt als Nächstes.

Wie soll das Importieren eines WebDB-Objektes technisch ablaufen?

Wer das mag, kann sich die Argumente eines "Viel-Fremdnutzers" von WebDB-Objekten - meine nämlich, schaut Euch die RUS-DB an bei den UEFA-CL und UEFA-Cup-Spielen - gerne noch mal weiter oben zu Gemüte führen.
Für das Übernehmen von fremden Objekten in die eigene DB ist immer Handarbeit angesagt, immer für jedes Objekt einzeln - spätestens beim Dublettenabgleich.

Daher halte ich es für absolut ausreichend, wenn einer Importfunktion die ID des gewünschten Objektes übergeben wird und diese Funktion dann das konkrete Objekt in die lokale DB holt.

Einzelheiten dazu Antwort #5.


Welche Varianten scheinen Euch noch erforderlich bzw. unbedingt nennenswert?

[jetset]

Daher halte ich es für absolut ausreichend, wenn einer Importfunktion die ID des gewünschten Objektes übergeben wird und diese Funktion dann das konkrete Objekt in die lokale DB holt.

Welche Varianten scheinen Euch noch erforderlich bzw. unbedingt nennenswert?

Ich denke, dass wir über das Wie nur über die Anzahl der einzugebenden IDs diskutieren sollten.

Meiner Meinung nach sollte man nicht nur eine ID eingeben können, sondern ruhig mehrere IDs. Die Vorgehensweise stelle ich mir folgendermaßen vor:

• Alle IDs, wie von GMT beschrieben heraussuchen
  
• eine lokal abgespeicherte Quell-(Web)DB angeben
  
• eine Liste der IDs eingeben und Import starten
  
• Dublettenabgleich durchführen
  

jetset

[arminho]

Zum WIE:
Ich teile mal auf in zwei Bereiche (Einzelimport und Ersetzung mehrerer Objekte):

EINZELIMPORT

Zunächst muss man da aus meiner Sicht zwei Dinge unterscheiden:
1.) Das Objekt befindet sich bereits (mit "falscher" ID) in der eigenen DB und man will die (Web)DB-ID importieren sowie die Spielerdaten ersetzen
2.) Man will ein neues Objekt importieren

Im ersten Fall ist sinnvollerweise die Ersetzung der ID im Importvorgang inbegriffen. Im zweiten Fall wird "lediglich" das Objekt importiert.

Stellvertretend für die verschiedenen Objekte das Vorgehen anhand eines Spielers:
Der Vorgang könnte aus der Spielerverwaltung über einen neu einzurichtenden Button gestartet werden. Der Vorgang würde den aktuell angezeigten Spieler betreffen bzw. wenn die Felder rechts leer sind ein neues Objekt. Hier ist noch die Frage, ob die Eingabe einer ID genügt (in ein neues Dummy-Feld) um den aktuell angezeigten Satz umzuwandeln bzw. einen neuen zu importieren. Oder ob man quasi eine Suche vorschaltet, um anhand der Inhalte der Felder Name, Vorname, Geburtsdatum und Nation eine Ergebnisliste anzuzeigen, aus der dann ausgewählt werden kann. Logisch, dass die zweite Alternative wesentlich aufwändiger ist.

Zwangsläufig bezieht sich diese Idee auf eine "fest" definierte Datenquelle. Ansonsten ist dieser Vorschlag nicht gangbar. Das WOHER lässt sich hier also nicht völlig raustrennen.


ERSETZUNG MEHRERER Objekte

Aus meiner Sicht nur mit vernünftigem Aufwand realisierbar über eine Textdatei mit den Werten
ID alt;ID neu
Vor einer Gruppe von ID-Paaren könnte das Objekt, z.B. [Spieler] stehen. Hier gilt zu dem WOHER im Prinzip das gleiche wie oben, wobei es hier (da nur eine einzige Startmaske) wesentlich einfacher wäre, die Quell-DB vorher auszuwählen. Da ist es dann schon eher eine Frage des Sinns, ob ich eine Massendatenersetzung nach verschiedenen Quell-DBs unterteilen möchte.

Alle anderen Möglichkeiten hinsichtlich einer Massenersetzung halte ich für zu aufwändig. Das Thema Massenimport ist, denke ich, richtigerweise vom Tisch.

[GMT]

Ich will mal ein Argument gegen das automatische Ersetzen in den Raum werfen:

Weiter oben versuchte ich schon mal anzudeuten, daß am Import von Objekten einer Art auch Objekte anderer Art hängen können.
Ganz konkret an einem Beispiel:
Ivica Olic hat einige Titel mit CSKA Moskva errungen. Jetzt wechselt der z.B. nach Polen (um nur mal eine beliebige Nicht-(Web)DB zu benennen). Würde Jarek den importieren, hätte er bei einer Übernahme der Titel auf einmal auch CSKA in der DB. Weil die Titel ohne die Mannschaft nicht in der DB dargestellt werden können.

Diese Art von automatischem "Objektnachziehen" kann zu den denkwürdigsten Verwicklungen führen. Daher glaube ich nicht, daß auch das ohne Weiteres möglich sein wird.


Bei einem automatischen Ersetzen eines Spielers würden zwangsläufig alle zusätzlich zu den Stammdaten selbst eingetragenen Informationen (selbst eingetragene Titel, Notizen usf.) gelöscht.
Daher sollte das Ersetzen nicht automatisch vorgenommen werden. Zumindest nicht ohne entsprechende Warnhinweise usf.
Will sagen: Das manuelle Dublettenlöschen für jedes einzelne Objekt sollte für den Alltagsgebrauch der primäre Weg sein.
Ob es zusätzlich einen quasi-automatischen gibt oder nicht halte ich momentan nicht für das Wichtigste.



Vielleicht ist ja auch statt einem Dublettenabgleich eine "Stammdatenübernahme" denkbar.

Das würde bedeuten, daß WebDB-Objekte von vornherein auf die Stammdaten reduziert importiert würden und dann anstelle des bekannten Dublettenlöschens diese Stammdaten diejenigen eines vorhandenen Objektes überschreiben würden. Ohne dabei dessen Nicht-Stammdaten (Notizen,  lokale eingetragene Titel usf.) zu löschen.

[jetset]

Vielleicht ist ja auch statt einem Dublettenabgleich eine "Stammdatenübernahme" denkbar.

Das würde bedeuten, daß WebDB-Objekte von vornherein auf die Stammdaten reduziert importiert würden und dann anstelle des bekannten Dublettenlöschens diese Stammdaten diejenigen eines vorhandenen Objektes überschreiben würden. Ohne dabei dessen Nicht-Stammdaten (Notizen,  lokale eingetragene Titel usf.) zu löschen.

Habe ich das jetzt richtig verstanden, dass du in den obigen Fall die Verlinkungen der "Stammdaten" nicht mit importieren willst?

Wenn nein, dann sollten wir uns auch eine Reihenfolge der Objekte überlegen, in der sie importiert werden sollte.

Ein Beispiel:

Eine Mannschaft wird importiert, an dem ein Stadion hängt, so sollte erst das Stadion und dann die Mannschaft importiert werden und zum Schluß die Verknüpfung zwischen beiden.

Aus meiner Sicht nur mit vernünftigem Aufwand realisierbar über eine Textdatei mit den Werten
ID alt;ID neu
Vor einer Gruppe von ID-Paaren könnte das Objekt, z.B. [Spieler] stehen. Hier gilt zu dem WOHER im Prinzip das gleiche wie oben, wobei es hier (da nur eine einzige Startmaske) wesentlich einfacher wäre, die Quell-DB vorher auszuwählen. Da ist es dann schon eher eine Frage des Sinns, ob ich eine Massendatenersetzung nach verschiedenen Quell-DBs unterteilen möchte.

Alle anderen Möglichkeiten hinsichtlich einer Massenersetzung halte ich für zu aufwändig. Das Thema Massenimport ist, denke ich, richtigerweise vom Tisch.

ich denke eine XML-Datei wäre hier dann sinnvoller. Ich denke mir den Aufbau dieser Datei ungefähr so:

<GlobalPlayerRecord>
<GID>4711</GID>
<GlobalPlayerName>Manuel Neuer/GlobalPlayerName>
        <GlobalNationalIndicator>Deutsch</GlobalNationalIndicato>
        <GlobalPlayerposition>Torwart</GlobalPlayerposition>
</GlobalPlayerRecord>

<GlobalStadiumRecord>
    <GID>4712</GID>
    <GlobalStadiumName>VeltinsArena</GlobalPlayerName>
    <GlobalNationalIndicator>Deutsch</GlobalNationalIndicato>
</GlobalStadiumRecord>


jetset

[GMT]

Was ich will, spielt hier keine Rolle. Wichtiger ist die Frage, was technisch machbar ist und keine Probleme verursacht.

Wir sind uns einig, daß jede DB in sich sauber sein und bleiben sollte? Fein.

Dann dürfen wir keine überflüssigen Dubletten erzeugen - bei keinem einzigen Objekttyp.

Jetzt stell' Dir bitte mal vor, Du könntest einen Spieler importieren, der Titel mit 5 verschiedenen Mannschaften gewonnen hat. Jede dieser Mannschaften hat in ihrer jeweils langen Geschichte in 7 verschiedenen Stadien gespielt.

Zugegeben, ich übertreibe leicht - aber das Problem wird klar: Auf einen Schlag hättest Du 36 neue Objekte in Deiner DB.

Sind das jetzt alles wirklich neue Objekte, ist nichts Schlimmes passiert. Gibt es aber auch nur ein einziges der Stadien bereits in Deiner DB, mit einer lokalen ID, dann hätten wir gerade eine Dublette erzeugt.

Einen Mechanismus zu finden, der das ausschließt und der Dir mit ausreichender Deutlichkeit sagt: Hier müssen erst noch die folgenden zusätzlichen, mitgelieferten 35 Objekte auf eventuelle Dubletten überprüft werden, einen solchen Mechanismus wird es kaum geben - es sei denn, man verzichtet auf die "Mitlieferung".

Das war auch der Hintergrund der Frage nach dem Zweck des Imports: Für das gemeinsame Nutzen der MyMedia-Archive reicht die Stammdatenübernahme allemal aus.

Und wenn Du Sorge um Deine lokalen Informationen wie Notizen, Titel, Verknüpfungen z.B. zu Stadien hast - die würden ja durch eine reine Stammdaten-Ersetzung gerade nicht berührt.

[GMT]

Deinen Gedanken an XML-Export denke bitte nicht weiter:

Keinesfalls wird es eine Möglichkeit geben, daß Daten tatsächlich exportiert werden können - wir reden hier über einen Import innerhalb des Studios aus einer noch nicht zu Ende diskutierten Quelle in eine Nicht-(Web)DB.
Eine XML-Datei würde den Import in beliebige andere Datensammlungen ermöglichen - keine Chance.

[GMT]

Nebenbei: In Deinem XML-Beispiel fällt mir ein erheblicher Mangel auf! Zufall?

Die GID wird innerhalb des Studios überhaupt nicht benötigt. Sie ist quasi für das Studio völlig irrelevant.
Bedeutung hat sie allein für die Verbindung zu MyMedia-Archiven !!!

Entscheidend im Studio ist die ID.

Und die finde ich in Deinem Beispiel überhaupt nicht.


Aber das nur am Rande, damit keiner von uns ID sagt, wenn er GID meint.  :
XML spielt ja für diesen Vorschlag keine Rolle.

[jetset]

Nebenbei: In Deinem XML-Beispiel fällt mir ein erheblicher Mangel auf! Zufall?

Die GID wird innerhalb des Studios überhaupt nicht benötigt. Sie ist quasi für das Studio völlig irrelevant.
Bedeutung hat sie allein für die Verbindung zu MyMedia-Archiven !!!

Entscheidend im Studio ist die ID.

Und die finde ich in Deinem Beispiel überhaupt nicht.


Aber das nur am Rande, damit keiner von uns ID sagt, wenn er GID meint.  :
XML spielt ja für diesen Vorschlag keine Rolle.

Die Angaben in dem XML-Schnipsel war ein Beispiel und das war auch nur eine Fortführung der Idee von arminho mit der Textdatei. Du kannst auch gedanklich GID streichen und ID setzen. Das waren Daten aus dem hohlen Bauch heraus.

Zugegeben, ich übertreibe leicht - aber das Problem wird klar: Auf einen Schlag hättest Du 36 neue Objekte in Deiner DB.

Nö du übertreibst nicht. Es gibt tatsächlich solche Fälle (Ronaldo -> Eindhoven, Inter, AC Milan, Real, Barca) in den unterschiedlichsten DB.

Wir sind uns einig, daß jede DB in sich sauber sein und bleiben sollte? Fein.

Dann dürfen wir keine überflüssigen Dubletten erzeugen - bei keinem einzigen Objekttyp.

Das steht doch ausser Frage und das ist ein weiteres Ziel des Imports. Deshalb ist es auch notwendig bei vorhandenen Objekten einen Abgleich durch zuführen, egal ob manuell oder automatisch.

[GMT]

Die Angaben in dem XML-Schnipsel war ein Beispiel und das war auch nur eine Fortführung der Idee von arminho mit der Textdatei. Du kannst auch gedanklich GID streichen und ID setzen. Das waren Daten aus dem hohlen Bauch heraus.

Sei mir nicht böse, aber ich finde hier im Forum zuhauf Informationen zu Objekten, bei den die GID mitgeliefert wird. (Spieler Kuchenblech, GID 47110815).
Daher bemühe ich mich hier immer um Klarheit und verwende selbst die GID niemals - um schweigende Mitleser nicht zu verwirren.