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

[jetset]

Hallo,

nachdem ich mich etwas intensiver mit dem Ligasystem beschäftigt habe und ein Ligasystem für Deutschland mit den vorhandenen Datenbanken erstellt habe, ist mir aufgefallen, dass ab der 3. Ebene und den Nicht-(WEB)DB natürlich unterschiedliche Daten vorhanden. Dieser Zustand liegt in den unterschiedlichen GID bei gleicher Bezeichnung der Objekte begründet.

Beispiel:

1. Bundesliga, 2. Bundesliga, 3. Liga:    GID 95                  Wattenscheid 09
Regionalliga West/SüdWest            :    GID 1806656512      SG Wattenscheid
Oberliga Westfalen                        :    GID 1560411120      SG Wattenscheid 09

Um dieses Problem zu beheben, kann ich mir eine Importfunktion für Mannschaften, Spieler, Stadien und Schiedsrichter vorstellen, damit eine Einheitlichkeit der Daten gewährleistet ist. Denn es gehört nicht nur die Quantität und Vollständigkeit zur Qualitätsbewertung von Daten (siehe Ranking), sondern auch die Einheitlichkeit.

Die Vorgehensweise beim Import stelle ich mir folgendermaßen vor:

a) Anlegen einer Nicht-(WEB)DB oder Ändern
b) Download einer (WEB)DB oder Aktualisierung
c) Import der Objekte aus der (WEB)DB in die Nicht-(WEB)DB

Kein Zugriff auf die (WEB)DB, also alles offline und alles innerhalb des DFS

Für die bestehenden Nicht(WEB)DB müßte dann die Dublettenermittlung erweitert werden, damit die bestehenden Daten mit den Importdaten abgeglichen werden können.

Gruß
jetset

[chrisi]

So wie ich das verstehe, soll hier das Verfahren, was normalerweise für Neulinge in der Web-DB durchgeführt werden, für alle geöffnet werden, nur halt offline. Korrigiert mich wenn ich falsch liege. 


Wenn nicht, bin ich dagegen. Zu hoher Programmieraufwand im Vergleich zum Nutzen. Man würde diese Funktion genau einmal nutzen und dann nie wieder. :

[jetset]

So wie ich das verstehe, soll hier das Verfahren, was normalerweise für Neulinge in der Web-DB durchgeführt werden, für alle geöffnet werden, nur halt offline. Korrigiert mich wenn ich falsch liege. 


Wenn nicht, bin ich dagegen. Zu hoher Programmieraufwand im Vergleich zum Nutzen. Man würde diese Funktion genau einmal nutzen und dann nie wieder. :

Hallo Chrisi,

es geht einfach, darum die Daten einheitlich zu halten. Die Funktionalität dürfte vorhanden sein, oder wie wird die (WEB)DB nach den Spieltagen für das Live Update aktualisiert?

Ich persönlich finde es ganz schön unsauber, wenn ich allein in 3 DB's aus Deutschland 3 mal eine verschiedene Schreibweise von Mannschaftsnamen habe. Besonders fällt dies im Ligasystem auf. Wenn ich nun die Daten manuell anpasse, kann ich die Anpassung nach jedem komplett Update neu ändern.

Gruß
jetset

[vmLOGIC]

Ich verstehe sehr gut was du meinst, jetset.
Überlegungen, wie ich hier Abhilfe schaffen kann, geistern mir immer mal wieder durch den Kopf. Vor allem die Frage, wie man sowas macht, ohne dass der DB-Ersteller am Initialaufwand verzweifelt.

Diskutiert ihr ruhig mal weiter. Ich lese interessiert mit. Vielleicht sind dann Geistesblitze für einen guten Lösungsansatz dabei.

P.S.
Ich habe übrigens niemals geschrieben (wie im anderen Thread vermutet), dass sämtliche Datenbanken mal (Web)DB-fähig werden sollen. Ganz im Gegenteil!!

[jetset]

P.S.
Ich habe übrigens niemals geschrieben (wie im anderen Thread vermutet), dass sämtliche Datenbanken mal (Web)DB-fähig werden sollen. Ganz im Gegenteil!!

Hallo Volker,

ich war mir ja auch nicht 100% sicher, aber es war mal eine Diskussion, um das Live Update.

Gruß
jetset

[GMT]

Damit hier nichts einschläft, versuche ich mal, meine noch nicht abgeschlossenen Überlegungen hier anzudeuten:

Zwei Bedingungen (oder Schwierigkeiten oder Probleme) gibt es von vornherein:

• Das Programm kann nur eine DB gleichzeitig öffnen - ich meine so, daß alle Studio-Funktionen zur Verfügung stehen.
  Das DB-Zusammenführen zeigt ja, daß die Informationen einer andere DB eingelesen werden können.
  
  
• Einen wie immer gearteten Listen-Export, der das Auslesen von Spieler- und sonstigen Daten im großen Umfang ermöglicht, sollte es nicht geben.

Das bedeutet von vornherein, daß jedes Objekt aus einer (Web)DB zuerst mal gefunden und seine ID extern erfaßt werden muß.
Ggf. mit Zusatzinformationen wie Postion und Rückennummer bei einem Spieler.
Denn diese Funktion würde potentiell sicher auch (sehr spezielles Beispiel) von Axel04 genutzt, um ein russisches Team in die UEFA-Cup-DB einzugeben, ohne erst neue eigene Spieler anzulegen. Die könnten direkt aus meiner RUS-DB übernommen werden.


Nun stelle ich mir folgendes vor:
Aus der Objektverwaltung (der anschließenden Zuordnung wegen) rufe ich den Objektimport auf.

Zunächst wäre dort eine lokal abgespeicherte Quell-(Web)DB anzugeben, die natürlich vorhanden und nicht im versandvorbereiteten Zustand sein muß. Diese Angabe müßte sich der Objektimport "merken" für folgende Aufrufe bei derselben Programmsitzung.

Anschließend kann der Nutzer eine ID aus der (Web)DB angeben, die dann in seine DB importiert wird. Dabei wird das importierte Objekt zum aktuell ausgewählten in der Verwaltungsfunktion.
Das ermöglicht ihm, den Objektimport zu verlassen und z.B. den gerade importierten Spieler direkt in einen Mannschaftskader einzufügen.

Ideal wäre, wenn dieselbe Funktion auch den Dublettenabgleich durchführen könnte. Angabe der internen ID - Angabe der Original-ID - "Wollen sie wirklich?" - Abgleich.
Wobei die Original ID vielleicht nicht zwingend eine aus der (Web)DB sein muß - habe ich in der Verwaltung eine Dublette entdeckt, wäre dies eine sehr schnelle Möglichkeit zum Beseitigen der einen Dublette.



Noch nicht zu Ende gedacht ist z.B.:
Inwieweit ist es sinnvoll oder kontraproduktiv, alle in der (Web)DB enthaltenen Informationen zum Objekt zu übernehmen?
Beispiel: Die Titel-Historie eines Spielers müßte in vielen Fällen zusätzliche Objekte (Mannschaften z.B.) aus der (Web)DB mitbringen, die dann lokal zu Dubletten führen könnten. Ohne diese zusätzlichen Objekte wäre die Historie von vornherein nicht vollständig.
Verzichte ich nun aus diesem Grund völlig auf die Übernahme der Titel-Historie, sollten beim Dublettenabgleich die bei der Dublette lokal eingetragenen Titel unberührt bleiben.


Weitere Gedanken verkneife ich mir hier, sonst kann das niemand mehr erfassen.
Für einen Denkanstoß und eine Fortsetzung der Diskussion sollte das allemal reichen.

[Gabor70]

Ich finde die Idee sehr gut. Das Problem ist der Umfang.

Es müsste eine Art "Master"-DB geben, aus der jeder, der eine DB erstellen möchte, zurückgreifen kann. Nur, wie groß wäre dann diese "Master"-DB? Sie würde wahrscheinlich jeden Rahmen sprengen.
Lösung wären regionale "Master"-DB's für Mannschaften, "Master"-DB's für Spieler etc.
So bräuchte jeder Ersteller "nur" die DB's zu laden, die er braucht.

[Plotsch]

Prinzipiell halte ich die Idee für sehr gut, könnte doch ein grundlegendes Problem angegangen werden:

Die Inkonsisstenz der "Stammdaten" in den Unterschiedlichen DB's.

Ich ärgere mich beispielsweise immer, wenn ich in den Südamerika-DB's unterschiedliche Informationen in unterschiedlichen DB's finden (eine Anpassung per Hand würde geradezu lächerlich viel Zeit in Anspruch nehmen und wozu hat man schließlich IT!)

Also von mir  O0 O0 O0 O0.


Insgeheim würde ich sogar für die Idee von Gabor70 stimmen... aber ich befürchte das ist nicht Mehrheitsfähig...

MfG

Plotsch

[Hermi]

Ich finde die Idee sehr gut. Das Problem ist der Umfang.

Es müsste eine Art "Master"-DB geben, aus der jeder, der eine DB erstellen möchte, zurückgreifen kann. Nur, wie groß wäre dann diese "Master"-DB? Sie würde wahrscheinlich jeden Rahmen sprengen.
Lösung wären regionale "Master"-DB's für Mannschaften, "Master"-DB's für Spieler etc.
So bräuchte jeder Ersteller "nur" die DB's zu laden, die er braucht.

Diese Idee finde ich sehr gut, denn damit hätten alle DB Ersteller die gleichen Angaben von Mannschaften, Spielern, Trainern und Schiedsrichtern.
Läßt sich das irgendwie machen.?
(vielleicht noch getrennt nach Deutschland, Europa, alle Welt ?) und diese DB im System ablegen worauf dann alle Zugriff haben.

[GMT]

Also bevor wir uns jetzt verlaufen, wollen wir alle nochmal den ersten Beitrag lesen, ja?

Worum geht es hier eigentlich?

Wir unterscheiden zwei völlig unterschiedliche Ausgangssituationen:
1. Jemand möchte eine neue DB beginnen und möchte möglichst viele Daten aus der WebDB vorab haben:
Alle verfügbaren (Web)DB hernehmen, in eine zusammenführen - fertig.

(Rein interessehalber - Falls sich jemand mal den Spaß macht: Wie groß ist denn die DB dann?)

Eine "Master-DB" gibt es  bereits. Sie heißt, wie allen bekannt ist, WebDB.
Der Zugang zur WebDB wird von Volker festgelegt.

2. In einer bestehenden DB möchte ein Ersteller Objekte nicht neu anlegen, wenn er sie samt ID und GID (Stichwort: MyMedia-Archive) in einer (Web)DB bereits finden kann. Er möchte diese Daten in seine DB übernehmen können.

Das genau ist die hier betrachte Frage.  Und bei der wollen wir bitte bleiben.

[jetset]

Noch nicht zu Ende gedacht ist z.B.:
Inwieweit ist es sinnvoll oder kontraproduktiv, alle in der (Web)DB enthaltenen Informationen zum Objekt zu übernehmen?
Beispiel: Die Titel-Historie eines Spielers müßte in vielen Fällen zusätzliche Objekte (Mannschaften z.B.) aus der (Web)DB mitbringen, die dann lokal zu Dubletten führen könnten. Ohne diese zusätzlichen Objekte wäre die Historie von vornherein nicht vollständig.
Verzichte ich nun aus diesem Grund völlig auf die Übernahme der Titel-Historie, sollten beim Dublettenabgleich die bei der Dublette lokal eingetragenen Titel unberührt bleiben.

Interessant finde ich deinen Gedanken von der Übernahme der Titel.Historie GMT.

Meine Meinung ist, dass der DB-Ersteller entscheiden sollte, auf welches Qualitätsniveau er seine DB bringen möchte. Bin ich ein Perfektionist in Sachen Daten, dann übernehme ich die Titel-Historie, wenn nicht, dann bleibt sie halt weg.

Übernehme ich jetzt die Titel-Historie, stellt sich die Frage, wieviel von der Historie übernehme ich?
Übernehme ich die komplette Historie oder nur den Teil, der für meine DB relevant ist?

Soll die Titel-Historie in historischen DB's weitergeführt werden? Sollte die Titel Historie als Kriterium für das Ranking einer DB aufgenommen werden?

Jetset

[GMT]

Hier liegst Du falsch: Dieser Gedanke hat technische Hintergründe.

Bei einem Blick in mehrere (Web)DB, die ein und desselben Spieler enthalten, wirst Du feststellen, daß die Titelhistorie des Spielers überall gleich ist (Idealfall. Abweichungen aus technischen Gründen sind möglich).

Als ich Anfang des Jahres Serhiy Rebrov aus Kees DB übernahm, als der von Dinamo Kiyv zu Rubin Kazan wechselte, bekam ich seine ganzen Titel mit. Die natürlich Kees eingegeben hatte. Und auch den russischen Meistertitel 2008 mußte natürlich Kees eingeben.


Ich bin mir sicher, daß Volker hier keine Auswahlmöglichkeit bereitstellen wird, wenn er denn ...
Entweder übernimmt ein Ersteller ein Objekt oder eben nicht.

Und ich habe die Frage aus denselben technischen Gründen hier angedeutet. Auch damit die Nicht(Web)DB-Ersteller einen Eindruck bekommen, was da noch so alles dranhängen kann...

[Kees]

Als ich Anfang des Jahres Serhiy Rebrov aus Kees DB übernahm, als der von Dinamo Kiyv zu Rubin Kazan wechselte, bekam ich seine ganzen Titel mit. Die natürlich Kees eingegeben hatte. Und auch den russischen Meistertitel 2008 mußte natürlich Kees eingeben.

Ganz kleine Korrektur. 

Rebrov gehört zu Kuddel.  ;D  Ansonsten inhaltlich:  O0  d'accord

Gruß aus dem Teutoburger Wald

[bignike]

Eine Master DB (offline) Nein danke, wer sollte diese bitte pflegen und wo bereit stellen.

Ich kann die Problematik sehr gut verstehen von Jetset.

Allenfalls müsste man die Synchronisation der Mannschaft erweitern und analog, zum Dubletten abgleich eine Funktion schaffen, die sagt

Rot "wird zu" Grün, resp. die

SG Wattenscheid 09 (GID 1560411120) ist = Wattenscheid 09 (GID 95) und zusammengefügt werden.

[GMT]

bignike, bist Du sicher, daß Du das Thema komplett gelesen hast? 

[bignike]

ja habe ich ...

die "Titelvererbung" lasse ich mal weg.

[GMT]

Dann nochmal um sicher zu gehen:

Ich habe jetset so verstanden, daß er WebDB-Objekte aus einer oder mehreren (Web)DB - was man halt so bekommen kann per Download - in eine bestehende DB übernehmen möchte.

Die Vorgehensweise beim Import stelle ich mir folgendermaßen vor:

a) Anlegen einer Nicht-(WEB)DB oder Ändern
b) Download einer (WEB)DB oder Aktualisierung
c) Import der Objekte aus der (WEB)DB in die Nicht-(WEB)DB

Kein Zugriff auf die (WEB)DB, also alles offline und alles innerhalb des DFS

Die Variante "Anlegen einer Nicht-(WEB)DB" ist relativ uninteressant, da das durch den Algorithmus "Herunterladen aller interessierenden (WEB)DB - Zusammenführen - überflüssige Daten löschen" bereits heute ohne Volkers weiteres Zutun geht.

Die Variante "Ändern" dagegen führt (möglicherweise) zu der von mir oben angedeuteten Funktion.

Während ich Dein

Allenfalls müsste man die Synchronisation der Mannschaft erweitern und analog, zum Dubletten abgleich eine Funktion schaffen, die sagt

Rot "wird zu" Grün, resp. die

SG Wattenscheid 09 (GID 1560411120) ist = Wattenscheid 09 (GID 95) und zusammengefügt werden.

nicht nachvollziehen kann - woher soll in einer bestehenden DB die Wattenscheid 09 (ID 95) herkommen? (Falls diese DB nicht aus einer früheren DFS.vmd erzeugt wurde.)

jetsets Punkt c) sagt eindeutig, er möchte die (Web)DB-Objekte in die Nicht-(Web)DB importieren.

[Vat]

Hi,

ich bin kein DB-Ersteller, deswegen entschuldige ich mich voraus wenn ich etwas falsch verstanden habe... 

2. In einer bestehenden DB möchte ein Ersteller Objekte nicht neu anlegen, wenn er sie samt ID und GID (Stichwort: MyMedia-Archive) in einer (Web)DB bereits finden kann. Er möchte diese Daten in seine DB übernehmen können.

Da kommt mir sofort das Stichwort "XML-Schnipsel" in den Gedanken, wie die Daten von DFS zum MMO übertragen werden. Es ist hier leider nicht möglich, weil man 2 DFS-Instanzen gleichzeitig nicht starten kann. Es bleibt dann mit einer XML-Bufferdatei zu arbeiten. Man legt Objekte aus einer DB (Master-DB) mit der Hilfe von XML-Schnipsel in die XML-Bufferdatei. Dann öffnet man eigene DB und kann diese Objekte aus der XML-Datei "importieren". Das wird zwar sicherer und schneller als einfach abtippen, aber immer noch zu mühsam.

Mit 2 DFS-Instanzen, die gleichzeitig laufen, könnte es man viel geschickter machen ... 

[jetset]

Hallo,

ich sehe, dass ich hier einige Mißverstädnisse ausgelöst habe, deshalb möchte ich anhand eines Beispiels dies verdeutlichen:

Bayern München spielte bis zum Aufstieg 64/65 in der Regionalliga Süd.
Blau Weiß 90 Berlin hat in der Regionalliga Berlin gespielt.
Westfalia Herne hat in der Regionalliga West gespielt.

(alle 3 Mannschaften sind in der DFS.vmd vorhanden)

a) Anlegen der DB regionalligen_63_74.vmd
b) Import von Mannschaften aufrufen.
c) Eine DB wie beim Zusammenführen von DB's eingeben (hier: DFS.vmd)
d) Auswählen von Objekt Bayern München, Blau Weiß 90 und Westfalia Herne
e) Importvorgang durchführen


Änderung in der Oberliga Westfalen von Wattenscheid 09:

a) Öffnen der Oberliga Westfalen DB
b) Import von Mannschaften aufrufen.
c) Eine DB wie beim Zusammenführen von DB's eingeben (hier: DFS.vmd)
d) Auswählen vom Objekt Wattenscheid 09
e) Importvorgang durchführen
f) Dublettenabgleich von den beiden Objekten Wattenscheid 09

Und schon hat man einen gleichen Stand von den Objekten in den DB's ohne eine "Master-DB" und nur von Studio-DB zu Studio-DB.

Ist die Mannschaft nicht in den Ligen der SEK 1-3, dann die entsprechende DB aus der nächst tieferen SEK nutzen.

Ich hoffe, dass es mit diesem Beispiel etwas klarer geworden.
In diesem Sinne
jetset

[Vat]

Hallo @jetset,

du willst also bei einer geöffneten DB eine andere DB öffnen, darin suchen und die Objekte daraus exportieren. Theoretisch klingt es einfach (mindestens machbar), praktisch ... weiß nur vmLOGIC. Aber ich denke, wenn das praktisch relativ einfach wäre, hätte er das schon längst getan. 

[GMT]

jetset, das erste von Deinen vorgenannten Beispielen ist das Anlegen einer neuen DB, richtig?

Läßt sich das nicht auch durch das Hernehmen der DFS.vmd, Umbenennen in regionalligen_63_74.vmd, Löschen der für diese DB nicht erforderlichen Daten usf. machen?

Ist dann ist der Kern Deines Vorschlages nicht das Importieren eines Teams aus z.B. der DFS.vmd in eine bestehende DB?

Liege ich mit meinen Gedanken also neben Deinem Vorschlag oder habe ich ihn getroffen?

Wenn daneben, dann wo?

[jetset]

Hallo GMT,

ja, das erste Beispiel ist das Neuanlegen einer DB. Ich habe es versucht aus mehreren DB's eine Regionalliga DB zu erstellen (Zusammenführen mehrerer DB's). Ich bin aber an den Daten aus dem geschützten Bereich gescheitert.
Ich brauchte ja nicht nur Daten aus der DFS.vmd sondern auch aus anderen DB's.

Okay, der Vorschlag hat im Kern die Aussage, den Import aus einer DFS DB in eine bestehen DB. Ich sehe, dass du den Kern meines Vorschlags richtig erkannt hast.

@All

Wir können gerne weiter über den Vorschlag diskutieren, damit wir eine für das DFS brauchbare Lösung finden, die von allen akzeptiert wird.

jetset

[Plotsch]

(Rein interessehalber - Falls sich jemand mal den Spaß macht: Wie groß ist denn die DB dann?)

220 MB  O0

Ich hatte mir den Spass mal gemacht, weil ich mir eine Master DB anlegen wollte...

Läßt sich das nicht auch durch das Hernehmen der DFS.vmd, Umbenennen in regionalligen_63_74.vmd, Löschen der für diese DB nicht erforderlichen Daten usf. machen?

Genau darin liegt in meinen Augen das Problem. Die Daten der WebDB Datenbanken lassen sich ja nicht mehr löschen. Somit "schleppt" man bei der Wiederverwendung immer einen Großteil an Daten mit, den man vielleicht gar nicht braucht.
Die Integration von Daten in bestehende nicht-WebDB's ist gar nicht möglich.

Okay, der Vorschlag hat im Kern die Aussage, den Import aus einer DFS DB in eine bestehen DB.

Ich fände es gut, wenn die mögliche Lösung dieses  Themas NICHT  nur WebDB's beinhaltet, sondern der Import von Daten (Mannschaften, Spieler, Trainer etc.) prinzipiell zwischen DB'S möglich ist. Es gibt inzwischen ja viele DB's bei denen man aufgrund des hohens Qualitätsstands, gerne mal den einen oder anderen Mannschaftssteckbrief importieren würde. Dann könnte man sich nämlich das stupide abtippen gelegentlich sparen.

MfG

Plotsch

[GMT]

220 MB  O0

:o - da darfst Du nicht mit einem Uralt-Rechner herangehen.  ;D
Danke für die Info

Die Daten der WebDB Datenbanken lassen sich ja nicht mehr löschen. Somit "schleppt" man bei der Wiederverwendung immer einen Großteil an Daten mit, den man vielleicht gar nicht braucht.

Verstehe ich nicht: Alle benötigten Daten in die neu zu pflegenden Ligen eingeben - in den Verwaltungsfunktionen nach "nicht verwendet" filtern - "Nicht verwendete löschen".
Schon sind (fast) alle nicht benötigten Daten weg.

Die Integration von Daten in bestehende nicht-WebDB's ist gar nicht möglich.

??? - Du meinst derzeit? - Dann ja, darum geht es ja gerade.

Ich fände es gut, wenn die mögliche Lösung dieses  Themas NICHT  nur WebDB's beinhaltet, sondern der Import von Daten (Mannschaften, Spieler, Trainer etc.) prinzipiell zwischen DB'S möglich ist.

Ich lehne mich mal weit aus dem Fenster mit einer Prognose: Das wird nichts.

Dafür gibt es einen ganz einfachen, aber ebenso schlagenden Grund: Importierst Du ein Objekt aus einer (Web)DB, dann hat das eine einheitliche ID in der WebDB und in allen (Web)DB. Und kommt nur auch nur unter dieser einen ID vor. Solltest Du ein Gegenbeispiel finden, wird diese Dublette umgehend beseitigt und wir kehren zum vorigen Satz zurück..

Damit ist der Import eines solchen Objektes gefahrlos: Gibt es diese ID in der Ziel-DB schon, gehört sie zum selben Objekt. Kein Problem.

Nicht (Web)DB-Ersteller können keine Objekte erzeugen, die ID im WebDB-Bereich haben.
Die  Nicht-Web-ID liegen alle im selben Zahlenbereich und - noch schlimmer - fangen alle beim selben Startwert an.
Eine Einheitlichkeit der Daten zwischen Nicht-(Web)DB kann es aus diesem Grund nicht geben.
Wo läge dann der Sinn des Imports?

[arminho]

Hier mein Statement zu dem Vorschlag:

Ich stimme in den meisten Punkten mit GMT überein. Eine neue Datenbank erstellen mit so einer Funktion halte ich für Quatsch. Das kann man sinnvoller so lösen wie GMT das herausgearbeitet hat. Für einzelne Spieler, Schiedsrichter etc.: warum nicht!?

Beim Einzel-Import von Objekten kann man vielleicht die Import-Funktionen nutzen, die es bereits gibt. Nur die Abfrage der hier sogenannten Master-DB läuft logischerweise anders. Technisch sollte das kein Problem sein.

Auch die Zusammenfassung von Datenbanken gibt es schon. Hier könnte jeder eine eigene Master-DB aus den gewünschten/benötigten (WebDB-fähigen) DBs zusammenstellen.

Es kam häufiger mal die Frage auf, wie das ist mit zwei gleichzeitig geöffneten Datenbanken, weil DFS das ja nicht zulässt. Aus meiner Sicht sind das zwei paar Schuhe. Nämlich Anwendung (DFS) auf der einen und Datenbank (VMD) auf der anderen Seite. DFS kann ja sinnvollerweise nur eine DB gleichzeitig anzeigen, warum sollten dann zwei gleichzeitig geöffnet werden können? Trotzdem ist es kein Problem auf eine andere DB zuzugreifen (OLE, ODBC, ADO). Ein Export nach XML oder ähnliches und nachfolgender Import: das kann's eigentlich nicht sein. Mit den vorgenannten Techniken kann ich Tabellen auch aus "fremden" Datenbanken verlinken oder zumindest ansprechen.

Ansonsten gibt es vielleicht noch ein paar grundsätzliche Fragen:

Soll der User die DB auswählen können oder arbeitet man mit einem festen Namen? (an dieser Stelle spreche ich auch nur vom Programmieraufwand, nicht von der Machbarkeit).
Gibt es eine "feste, offizielle" Master-DB oder soll der User sich die Master-DB aus den gewünschten (und von ihm benötigten) Datenbanken selbst zusammenstellen (dürfen)?
Wie viel Aufwand will Volker in so eine Funktion stecken. Mit Suchmasken, Ergebnismasken etc. kommen da schnell ein paar Tage zusammen. Oder ist es ok, wenn der User die gewünschte ID zuvor in der anderen DB ausfindig gemacht hat und dann in seiner DB nur die ID zum Import eingibt? Letzteres begeistert mich nicht wirklich, weil hier wieder die Komponente "man kann nur einmal DFS gleichzeitig öffnen" ins Spiel kommt. Das gäbe unter Umständen ein ziemliches Hin und Her.

[jetset]

Hallo,

die Methode mit dem Zusammenführen von Datenbanken (z.B DFS.VMD und dfs_rlsued_olbayern.vmd) scheitert einfach daran, dass in der DFS.vmd mit öffentlichen ID's bestückt ist. Das Verfahren des Zusammenführen funktioniert nur mit DB's, in denen keine öffentlichen ID's enthalten sind.

Soviel zum Erstellen durch Zusammenführen:




Jetset

[GMT]

Soll der User die DB auswählen können oder arbeitet man mit einem festen Namen? (an dieser Stelle spreche ich auch nur vom Programmieraufwand, nicht von der Machbarkeit).
Gibt es eine "feste, offizielle" Master-DB oder soll der User sich die Master-DB aus den gewünschten (und von ihm benötigten) Datenbanken selbst zusammenstellen (dürfen)?

Einen festen Dateinamen für eine MasterDB halte ich für nicht sinnvoll. Ein Datei-Auswahl-Dialog ist bereits programmiert (Zusammenführen) und sollte keinen Aufwand verursachen.
Warum soll ein Nutzer erst mehrere DB zusammenführen (oder der Reihe nach umbenennen), wenn er Informationen aus verschiedenen (Web)DB braucht?

Oder ist es ok, wenn der User die gewünschte ID zuvor in der anderen DB ausfindig gemacht hat und dann in seiner DB nur die ID zum Import eingibt? Letzteres begeistert mich nicht wirklich, weil hier wieder die Komponente "man kann nur einmal DFS gleichzeitig öffnen" ins Spiel kommt. Das gäbe unter Umständen ein ziemliches Hin und Her.

Ich meine: ja, das ist ok.

Wer sich meine DB aufmerksam anschaut, findet dort EC-Spiele russischer Mannschaften.
Bei denen ich kann ich für eine glücklicherweise recht große Anzahl von "Gegner-Teams" auf Objekte=Spieler aus der WebDB zurückgreifen.

Mein Ablauf sieht dabei so aus: DB der betreffenden Liga öffnen - in der Spielerverwaltung den mich interessierenden Kader des Gegner-Teams aufrufen und von dort alle benötigten Spieler mit ID, Rückennummer und Position herausschreiben.
So richtig schön manuell in eine Liste.
Die drei genannten Angaben bekäme ich zwar auch auf andere Weise, hier sind sie aber schön zusammengefaßt; ich muß nicht suchen.
Anschließend rufe ich meine DB auf und hole mir über die ID die entsprechenden Spieler aus der WebDB in meine DB und füge sie dann mit Pos/RN in den Kader ein.

Dasselbe Verfahren hatte ich bei meinem Vorschlag oben im Sinn - nur daß natürlich die WebDB außen vor bleibt.

Will sagen: Bei sinnvoller Organisation bleibt das Hin und Her im Rahmen.

Zumutbar ist das Verfahren allemal.

Wie viel Aufwand will Volker in so eine Funktion stecken. Mit Suchmasken, Ergebnismasken etc. kommen da schnell ein paar Tage zusammen.

Die sollte er sich meiner Ansicht nach sparen können, wenn das Ganze über die ID abgewickelt wird.

[GMT]

Hallo,

die Methode mit dem Zusammenführen von Datenbanken (z.B DFS.VMD und dfs_rlsued_olbayern.vmd) scheitert einfach daran, dass in der DFS.vmd mit öffentlichen ID's bestückt ist. Das Verfahren des Zusammenführen funktioniert nur mit DB's, in denen keine öffentlichen ID's enthalten sind.

Soviel zum Erstellen durch Zusammenführen:




Jetset

So etwas kann auf zwei Arten passieren:
1. Der Nutzer hat nach dem Herunterladen eigene Daten eingegeben - und sei es unabsichtlich.
Lösung: Entweder die eigenen Daten löschen oder die (Web)DB nochmal herunterladen.

2. Die (Web)DB enthält tatsächlich öffentliche ID. Das wäre dann ein unglückliches Zusammentreffen gleich mehrerer Fehler des Erstellers, das eigentlich nie vorkommen sollte.
Lösung: Ersteller kontaktieren und auf diesen Umstand hinweisen. Allerdings bitte mit dem klaren Hinweis darauf, was man schon selbst alles überprüft hat.

Da das beides nicht der Standardfall ist, wollen wir das Thema bitte nicht weiter verfolgen. 

[arminho]

Einen festen Dateinamen für eine MasterDB halte ich für nicht sinnvoll. Ein Datei-Auswahl-Dialog ist bereits programmiert (Zusammenführen) und sollte keinen Aufwand verursachen.
Warum soll ein Nutzer erst mehrere DB zusammenführen (oder der Reihe nach umbenennen), wenn er Informationen aus verschiedenen (Web)DB braucht?

Naja, das einmalige Zusammenfassen spart ihm das ständige Hin und Her zwischen verschiedenen Datenquellen.
Ich würde für mich diesen Weg präferieren.
So oder so. Jeder Weg hat seine Vor- und Nachteile.

[GMT]

Für Massenaktionen wird man sich zweifellos die benötigten Quellen in eine DB zusammenführen.


Ich stelle mir die folgende Situation vor:

Jemand braucht schnell mal einen Spieler aus RUS und einen aus ENG.

Was ist wohl schneller - erst die beiden DB zusammenführen oder je einmal die Datei im Dialog auswählen?

[jetset]

Moin, Moin,

Worüber ich mir Gedanken machen, nachdem GMT die Titelhistorie angesprochen hat, was an Daten der Titelhistorie übernommen werden soll?

Ist das nicht abhängig von den Zeiträumen der Saisons, die ich anlege?
Ist das nicht abhängig von den Spielern, die angelegt werden?

Nehmen wir mal das Beispiel Bayern München und Sepp Maier in der Regionalliga Süd von 1963 bis 1965.

Bayern war zu diesem Zeitpunkt nur 1932 Deutscher Meister und Sepp Maier hatte noch keinen Titel. Sepp Maier wurde das erste Mal DM 1969 mit Bayern in der Bundesliga.

Jetzt stelle ich mir die Frage, ob ich die Daten aus der Bundesliga in die Regionalliga von 1963 bis 1974 übernehme, obwohl Bayern dort nur bis zur Saison 64/65 gespielt hat.

Werden alle Titel übernommen, so sollte man sich im Klaren sein, dass dann auch ein Wust an anderen Informationen übernommen werden muß. Der Weltmeistertitel von Sepp Maier zieht die Mannschaft Deutschland nach sich und an Deutschland hängen dann weitere Titel, die dann auch übernommen werden müssen.

Natürlich sind hier auch alle anderen Titel mit gemeint, wie z.B Spieler des Jahres, Weltmeister, etc...

Hat ein Spieler Erfoge mit 2 Mannschaften und die Entscheidung fiel auf alle Erfolge übernehmen, so sollten dann auch die 2. Mannschaft mit allen Erfolgen übernommen werden (siehe Titel Welt- oder Europameister).

Wird ein ehemaliger Spieler Trainer, soll dann auch die Rolle des Trainers mit allen Erfolgen übernommen werden?

Welche Stadien sollen denn für Bayern München übernommen werden? Grünwalder Str., Olympiastadion, Allianz-Arena??

Sollen Schiedsrichter nur für den Zeitraum der DB oder komplett übernommen werden?

Pokale und Länder können meiner Meinung nach schon bei der Erstellung komplett übernommen werden.

Gruß
jetset

[arminho]

die Wahl des Verfahrens ist doch immer abhängig vom Anteil der Informationem, die man braucht.

Richtig. Daher macht es sicher Sinn, hier vorher zu diskutieren, was letztlich gebraucht wird.

Worüber ich mir Gedanken machen, nachdem GMT die Titelhistorie angesprochen hat, was an Daten der Titelhistorie übernommen werden soll?

Ist das nicht abhängig von den Zeiträumen der Saisons, die ich anlege?
Ist das nicht abhängig von den Spielern, die angelegt werden?

Die Titel kommen nach jetzigem Stand immer alle mit, selbst wenn sie eine andere Liga oder sogar ein anderes Land betreffen. Ich denke, es gibt auch Befürworter dafür, alle verfügbaren Titel zu sehen/importieren. Logischerweise wären die Titel wenn man sie aus einer einzigen DB importiert eingegrenzt. Das würde dann auch dafür sprechen, alle benötigten DBs zusammenzufassen.

Für Massenaktionen wird man sich zweifellos die benötigten Quellen in eine DB zusammenführen.

Ich stelle mir die folgende Situation vor:
Jemand braucht schnell mal einen Spieler aus RUS und einen aus ENG.

Genau. Wie ich schon schrieb, es gibt für jede Option Vor- und Nachteile. Für die Auswahl der Einzel-DB spricht noch, dass sich die Informationen in den DBs ständig ändern. Für das Zusammenfassen spricht noch die Titelthematik von oben.

[GMT]

Zur Erläuterung: (bei teilweiser Wiederholung des bereits von arminho beschriebenen)

In jeder DB ist ein Spieler mit anderen Informationen verknüpft. Ein Teil davon - die Titel eben und mit diesen die zugehörigen Mannschaften - werden beim Importieren eines Spielers aus der WebDB in eine (Web)DB gleich mit übernommen.

Ich frage mich nun - und stelle das deshalb zur Diskussion - inwieweit das hier sinnvoll ist. Was nicht heißt, daß ich hier dafür oder dagegen bin.

Dafür spricht, daß damit mehr Informationen beim Spieler sind.
Dagegen spricht, daß damit quasi unbemerkt zusätzliche Informationen in die DB kommen, die dann Dubletten zu lokalen Objekten sein können.


Prinzipiell sollte hier aber schon klar sein, wozu das ganze Verfahren dient.
Dient es

• a) zur Übernahme von ID+GID, um MyMedia-Archive über mehrere, auch Nicht(Web)DB nutzen zu können oder
  
• b) sollen neben a) auch die sich ggf. in der WebDB und den (Web)DB ändernden Informationen zum Objekt mit aktualisiert werden.
  

Letzteres wäre eine Erweiterung des reinen Import-Gedankens, die bisher nicht zur Diskussion stand.
Und ich meine, daß das auch nicht wirklich erforderlich ist.

[GMT]

Sollen Schiedsrichter nur für den Zeitraum der DB oder komplett übernommen werden?

Diese (und nur diese) verstehe ich nicht von Deinen Fragen.

Schiedsrichter werden mit keinem anderen WebDB-Objekt übernommen.
Sie sind ausschließlich mit den Spielen verknüpft, in denen sie zum Einsatz kamen, und den Saisons, in denen sie "im SR-Kader sind".

Alles andere - ja, das käme in der Konsequenz entweder komplett mit oder komplett nicht.

[Vat]

Hi,

Titelhistorie wurde hier schon angesprochen, aber was ist mit Transferdaten? Werden sie übernommen? Ich bin mir sicher, dass diese Frage früher oder später sowieso auftauchen wird.

Ich stelle es mir vor, dass die "von" und "zu" Mannschaften, (nur die, die in Ziel-DB nicht existieren, oder sogar alle) durch die entsprechenden Notizen ersetzt werden können, damit man sie auch nicht mitschleppen soll.

[jetset]

[quote author=jetset link=topic=18668.msg130743#msg130743 date=1229675459]
Sollen Schiedsrichter nur für den Zeitraum der DB oder komplett übernommen werden?

Diese (und nur diese) verstehe ich nicht von Deinen Fragen.

Schiedsrichter werden mit keinem anderen WebDB-Objekt übernommen.
Sie sind ausschließlich mit den Spielen verknüpft, in denen sie zum Einsatz kamen, und den Saisons, in denen sie "im SR-Kader sind".

Alles andere - ja, das käme in der Konsequenz entweder komplett mit oder komplett nicht.
[/quote]

Da ich nicht den gesamten Durchblick der Technik habe, habe ich einfach mal die Gedanken niedergeschrieben, welche Objekte (Daten) in welchem Zeitraum man braucht. Dann bin ich der Meinung, dass man die Schiris komplett übernehmen kann.

Hi,

Titelhistorie wurde hier schon angesprochen, aber was ist mit Transferdaten? Werden sie übernommen? Ich bin mir sicher, dass diese Frage früher oder später sowieso auftauchen wird.

Ich stelle es mir vor, dass die "von" und "zu" Mannschaften, (nur die, die in Ziel-DB nicht existieren, oder sogar alle) durch die entsprechenden Notizen ersetzt werden können, damit man sie auch nicht mitschleppen soll.

Danke Vat, daran habe ich noch gar nicht gedacht. Ich denke, da sollte man analog mit der Titelhistorie vorgehen. Fallen Transfers in dem Zeitraum, die die DB abdeckt, existieren, dann ja, ansonsten denke ich nicht.

Ich frage mich nun - und stelle das deshalb zur Diskussion - inwieweit das hier sinnvoll ist. Was nicht heißt, daß ich hier dafür oder dagegen bin.

Dafür spricht, daß damit mehr Informationen beim Spieler sind.
Dagegen spricht, daß damit quasi unbemerkt zusätzliche Informationen in die DB kommen, die dann Dubletten zu lokalen Objekten sein können.


Prinzipiell sollte hier aber schon klar sein, wozu das ganze Verfahren dient.
Dient es

• a) zur Übernahme von ID+GID, um MyMedia-Archive über mehrere, auch Nicht(Web)DB nutzen zu können oder
  
• b) sollen neben a) auch die sich ggf. in der WebDB und den (Web)DB ändernden Informationen zum Objekt mit aktualisiert werden.
  

Letzteres wäre eine Erweiterung des reinen Import-Gedankens, die bisher nicht zur Diskussion stand.
Und ich meine, daß das auch nicht wirklich erforderlich ist.

Inwiefern ist es eine Erweiterung des Import-Gedanken, wenn ich über den Import Objekte aktualisiere oder existierende DB mit den vorhandenen Daten über die Import-Funktion berichtige?

jetset

[GMT]

Ich merke schon, Wir sind wieder mal bei der Frage, worum es hier eigentlich geht.

Gut, dann beantworte mir mal folgende Fragen:

1. Wozu willst Du den Import eigentlich haben?

1a) Willst Du einheitliche ID/GID für gleiche Spieler um z.B. Mymedia-Archive einheitlich nutzen zu können?
Dafür ist die Übernahme einer späteren Änderung des vollständigen Namens oder eines neuen Titels eines Spielers nicht erforderlich.

1b) Oder willst Du einfach alles, was in einer (Web)DB ist, frag- und kommentarlos in Deine DB übernehmen?
Dann bekommst Du massenhaft Daten mit, die Du gar nicht brauchst für Deine konkrete DB. Viel Spaß beim Löschen und DUblettenabgleichen.

1c) Oder willst Du über den Umweg einer Offline-Funktion Zugriff auf die WebDB-Daten haben, inklusive aller eventuellen Korrekturen, Neueinträge usf.? Das sind Deine Aktualisierungen.



Von der Antwort hängt ab, in welche Richtung man eigentlich überlegen muß.


Ich ging bisher von 1a aus - Du kannst mit einer Funktion nach meinen bisher geäußerten Vorstellungen gezielt beliebige Objekte aus einer (Web)DB übernehmen und gleich die entsprechende Dublette aus Deiner DB löschen.

Objekte können hierbei solche sein, für die es eine Verwaltungsfunktion im Studio gibt. Die heißt dann auch im Studio so. Mit anderen Worten Mannschaften, Spieler/Trainer, Schiris, Stadien

Bei einigen Objekten gibt es "Querverbindungen". Spieler/Trainer haben Titel und zugehörige Mannschaften. Mannschaften Titel und Stadien.


2. Müssen diese "querverbundenen" Objekte beim Import mitkommen?
Für einheitliche ID/GID ist das nicht erforderlich; es führt sogar ggf. zu unerwünschten Einträgen bzw. Dubletten.


Klar muß dann auch sein: Saisons, Spieltage, Spiele, Kader, Transfers sind keine Objekte, die in der WebDB vorhanden sind. Die sind alle rein lokal in jeder einzelnen Datenbank.
Die können nicht importiert werden - und ich sehe auch gar keinen Sinn darin.



Bitte geht diese Fragen jedesmal durch, bevor ihr die nächste Idee "Was würde ich gern noch alles importieren können?" hier äußert.

Dieser Thema sollte bitte nicht zum Ideenwettbewerb in dieser Richtung ausarten.

[jetset]

Ich merke schon, Wir sind wieder mal bei der Frage, worum es hier eigentlich geht.

1. Wozu willst Du den Import eigentlich haben?

Um Objekte(ID/GID, Manschaften, Spieler) von DB A nach DB B zu bekommen (egal Neuanlage oder Aktualisierung der Objekte).

1a) Willst Du einheitliche ID/GID für gleiche Spieler um z.B. Mymedia-Archive einheitlich nutzen zu können?
Dafür ist die Übernahme einer späteren Änderung des vollständigen Namens oder eines neuen Titels eines Spielers nicht erforderlich.

Ja.

1b) Oder willst Du einfach alles, was in einer (Web)DB ist, frag- und kommentarlos in Deine DB übernehmen?
Dann bekommst Du massenhaft Daten mit, die Du gar nicht brauchst für Deine konkrete DB. Viel Spaß beim Löschen und DUblettenabgleichen.

Deshalb die Frage nach dem Umfang der Objekte, die übernommen werden sollen (Datenumfang)

1c) Oder willst Du über den Umweg einer Offline-Funktion Zugriff auf die WebDB-Daten haben, inklusive aller eventuellen Korrekturen, Neueinträge usf.? Das sind Deine Aktualisierungen.

Von der Antwort hängt ab, in welche Richtung man eigentlich überlegen muß.


Ich ging bisher von 1a aus - Du kannst mit einer Funktion nach meinen bisher geäußerten Vorstellungen gezielt beliebige Objekte aus einer (Web)DB übernehmen und gleich die entsprechende Dublette aus Deiner DB löschen.

Objekte können hierbei solche sein, für die es eine Verwaltungsfunktion im Studio gibt. Die heißt dann auch im Studio so. Mit anderen Worten Mannschaften, Spieler/Trainer, Schiris, Stadien

Bei einigen Objekten gibt es "Querverbindungen". Spieler/Trainer haben Titel und zugehörige Mannschaften. Mannschaften Titel und Stadien.


2. Müssen diese "querverbundenen" Objekte beim Import mitkommen?
Für einheitliche ID/GID ist das nicht erforderlich; es führt sogar ggf. zu unerwünschten Einträgen bzw. Dubletten.


Klar muß dann auch sein: Saisons, Spieltage, Spiele, Kader, Transfers sind keine Objekte, die in der WebDB vorhanden sind. Die sind alle rein lokal in jeder einzelnen Datenbank.
Die können nicht importiert werden - und ich sehe auch gar keinen Sinn darin.



Bitte geht diese Fragen jedesmal durch, bevor ihr die nächste Idee "Was würde ich gern noch alles importieren können?" hier äußert.

Dieser Thema sollte bitte nicht zum Ideenwettbewerb in dieser Richtung ausarten.

Nö soll auch kein Wettbewerb werden, sondern nur etwas helfen, die verschiedenen DBs einheitlich zu halten, damit sie den gleichen Informationsgehalt haben.

Von Saisons und Spiele bin ich auch noch ausgegangen, sondern nur von den "Stammdaten" oder besser gesagt Objekte (Mannschaft, Spieler, Trainer, Schiris).

Ich verstehe folgendes unter Import (ETL Prozess):

• Extraktion (Extract) der relevanten Daten aus verschiedenen Quellen
  
• Transformation (Transform) der Daten in das Schema und Format der Zieldatenbank
  
• Laden (Load) der Daten in die Zieldatenbank.
  

Das Verfahren lässt sich als allgemeiner Prozess der Informationsintegration auch auf andere Datenbanken übertragen. Dabei gilt es, heterogen strukturierte Daten aus unterschiedlichen Quellen zusammenzuführen. Der Prozess muss sowohl effizient ablaufen, um Sperrzeiten bei den Quellen zu minimieren, als auch die Qualität der Daten sichern, damit sie trotz möglicher Änderungen der Quellen vollständig und konsistent gehalten werden können. (Sperrzeiten können hier vernachlässigt werden)

Ist das so schwer zu verstehen, was ich möchte?
einfach nur Objekt A aus DB A in die DB B als Objekt A inklusive der IDs/GIDs

[GMT]

Nein, der Kern ist schon klar.

Der Umfang nicht.

E versuche ich mit Einzelabfragen zu realisieren - dieses Verfahren nutzen die (Web)DB-Ersteller für den Import aus der WebDB in die lokale DB.

T entfällt, da das Format dasselbe ist.

L ist auch kein Problem - aus demselben Grund.


Und das zentrale Problem hier wird wohl sein, ob Du eine Massenabfrage haben möchtest (alles komplett mit allen Querinfos) oder eine gezielte Einzelabfrage.

Eine Einzelabfrage ist kein Hexenwerk; auch das Mißbrauchspotential ist klein.

Eine Massenabfrage führt entweder zu unverhältnismäßig viel unnötigen Daten oder muß ausgefeilt gefiltert werden. Letzteres gibt es noch nicht - es wurde bisher auch nicht gebraucht.


Das Aktualisieren ist dann ein Folgeproblem: Ein gezieltes Objekt einzeln zu aktualisieren ließe sich mühelos in denselbem Dialog wie Einzelextrakt integrieren.
Massenaktualisierungen sind wieder eine Extrasache.

Was also: Einzeln gezielt oder Massenabfragen?

Ist das so schwer zu verstehen, was ich möchte?
einfach nur Objekt A aus DB A in die DB B als Objekt A inklusive der IDs/GIDs

Das fragt doch nach Einzelabfragen - oder sehe ich das falsch?

[jetset]

[quote author=jetset link=topic=18668.msg130761#msg130761 date=1229696233]
Ist das so schwer zu verstehen, was ich möchte?
einfach nur Objekt A aus DB A in die DB B als Objekt A inklusive der IDs/GIDs

Das fragt doch nach Einzelabfragen - oder sehe ich das falsch?
[/quote]

Ob Einzel-  oder Massenabfrage ist doch abhängig von der Anzahl der Objekte, die ich aus den verschiedenen Quellen brauche?
Also ist deine Frage doch nicht von vorne herein mit Massen- oder Einzelabfrage zu beantworten.

[GMT]

Ich weiß auch, daß das Importieren von 200 Objekten über Einzelanfragen mühsamer ist als wenn Du das in irgendeiner Form automatisieren kannst.

In der Praxis mußt Du Dir trotzdem von vornherein diese Frage beantworten.
Weil der Einzelimport eines konkreten Spielers gleich mit der Möglichkeit verbunden werden kann, dessen lokale Dublette zu eliminieren - Du wolltest Doch vereinheitlichen, oder?

Wenn Du einen Massenimport machst, mußt Du anschließend in Deinem kompletten Spielerbestand diese Pärchen erstmal alle finden - was aufgrund unterschiedlicher Schreibweisen, Vor- und Nachnamenszuordnungen usf. oder ganz einfach kleinen Fehlern in den Daten auch keine einfache Aufgabe ist.

Selbst wenn es für mich schon eine Möglichkeit gäbe, Massenimport zu machen, würde ich trotzdem wie bisher jedes Objekt einzeln importieren, um es gleich abschließend einzufügen und und und ...

Ich bleibe bei der Frage: Was also willst Du?

[arminho]

Naja, dass man "mitten" in der Bearbeitung einer DB mal plötzlich 200 oder auch 50 Spieler auf einmal braucht ist ja eher unwahrscheinlich. Das kommt doch höchstens beim Aufsetzen einer neuen DB vor - und das Vorgehen hatten wir ja oben schon besprochen. Wie läuft es denn bei der WebDB? Man sucht den einzelnen Spieler, der einem gerade in einem Kader fehlt. Genauso würde es sicher mit einem lokalen "WebDB-Abbild" laufen.

Volker wollte ja, dass wir hier ein bisschen über das Thema diskutieren. Daher ist es nicht in erster Linie relevant, was jetset will, sondern wir sollten uns prinzipiell Gedanken machen, wie man eine solche Funktion sinnvoll umsetzen könnte.

Je mehr ich drüber nachdenke, umso eher würde ich alles in einer einzigen Master-DB zusammenfassen. Im Prinzip kann diese DB um die Spiele reduziert sein. Die braucht man ja für diesen Zweck nicht zwingend. Es geht ja in erster Linie um die einheitliche ID.

Auch ist es nicht zwingend, dass diese lokale Version ständig aktuell ist. Halbjährlich aktualisieren würde hier aus meiner Sicht genügen. Wenn ich aber mal schnell einen Spieler suche, ist es sicher besser wenn man nur in einer einzigen Quelle suchen muss, statt erst mal umständlich 4-5 DBs zu öffnen. Es mag noch nahe liegend sein, dass ich einen Tschechen erst mal in der Tschechien-DB suche (und selbst bei einem Tschechen ist es nicht gesagt, dass er aus der Tschechien-DB kommt, wie wir alle wissen), aber was ist mit einem Nigerianer? Dann kann ich quasi erst mal alle webfähigen DBs öffnen, um sicherzugehen, dass er nicht doch irgendwo drin ist. Nein, das Öffnen einer einzelnen DB ist eigentlich kein gangbarer Weg...

Nochmal zurück zu den Spielen: Wenn wirklich auf diesem Weg mal alle ID's der Spieler die in der WebDB vorhanden sind, in allen lokalen DBs gleich sind, könnte man als Erweiterung überlegen, komprimierte Saison-Spieldaten (so wie in dem Steckbrief der Spieler: Stationen - Saison - Spiele, Tore, Ein-/Auswechslungen, Karten) mit in die Master DB abzulegen (weiter oben gab es ja mal die Debatte über Transferdaten, die sich aber aus meiner Sicht nicht so ohne weiteres vereinheitlichen lassen). Mit komprimierten Saisondaten könnte man darauf verzichten und hätte die Information trotzdem - und noch in besserer Qualität. Gleichzeitig könnte man so den Gesamtblick auf eine Spielerkarriere verwirklichen wie man ihn von Transfermarkt.de oder Weltfussball.de kennt (bzw. eigentlich noch besser) - und die letzte kleine Lücke in DFS schließen...

[GMT]

Naja, dass man "mitten" in der Bearbeitung einer DB mal plötzlich 200 oder auch 50 Spieler auf einmal braucht ist ja eher unwahrscheinlich. Das kommt doch höchstens beim Aufsetzen einer neuen DB vor - und das Vorgehen hatten wir ja oben schon besprochen.

Oh, meinst Du?

DFB-Pokal-DB, FA-Cup und Länderspiel-DB aus den jeweiligen Landes-DB
UEFA-Cup, Champions-League aus allen vorhandenen Landes-(Web)DB
Africa-Cup, Copa America, Olympia Herren aus anderen Turnier-DB (WM, Confed-Cup)


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.

Reicht das an Beispielen für Datenbanken, wo ein solches Verfahren regelmäßig erforderlich ist?

Wo es in der Regel sich auf ein paar Dutzend bis einige Hundert - aber nicht im Unterschied zum Neuaufsetzen einer DB nicht Tausend(e) - Objekte beschränkt?


Hier sehe ich die Hauptanwendung einer solchen Möglichkeit - und hatte durchaus im Hinterkopf, welche DB jetset selbst pflegt.

Eine Master-DB wäre für die viele der hier betrachteten Fälle (Abstieg, Cup) ein zusätzlicher, sachlich nicht zwingend erforderlicher Schritt ...

[jetset]

Volker wollte ja, dass wir hier ein bisschen über das Thema diskutieren. Daher ist es nicht in erster Linie relevant, was jetset will, sondern wir sollten uns prinzipiell Gedanken machen, wie man eine solche Funktion sinnvoll umsetzen könnte.

Je mehr ich drüber nachdenke, umso eher würde ich alles in einer einzigen Master-DB zusammenfassen. Im Prinzip kann diese DB um die Spiele reduziert sein. Die braucht man ja für diesen Zweck nicht zwingend. Es geht ja in erster Linie um die einheitliche ID.

Auch ist es nicht zwingend, dass diese lokale Version ständig aktuell ist. Halbjährlich aktualisieren würde hier aus meiner Sicht genügen. Wenn ich aber mal schnell einen Spieler suche, ist es sicher besser wenn man nur in einer einzigen Quelle suchen muss, statt erst mal umständlich 4-5 DBs zu öffnen. Es mag noch nahe liegend sein, dass ich einen Tschechen erst mal in der Tschechien-DB suche (und selbst bei einem Tschechen ist es nicht gesagt, dass er aus der Tschechien-DB kommt, wie wir alle wissen), aber was ist mit einem Nigerianer? Dann kann ich quasi erst mal alle webfähigen DBs öffnen, um sicherzugehen, dass er nicht doch irgendwo drin ist. Nein, das Öffnen einer einzelnen DB ist eigentlich kein gangbarer Weg...

Ist das richtig, dass die WEB-DB von den DB-Erstellern der Live-Update-fähigen DBs gepflegt wird?

Kann eine DB ohne Saison angelegt werden?

Ich würde auch die "Master-DB" zusammen stellen bzw. plegen.

In dieser Master-DB brauchen wir doch nur folgende Objekte:

• Mannschaften
  
• Spieler
  
• Schiedsrichter
  
• Stadien
  

Spiele und Saisons werden meiner Meinung nicht gebraucht. Was ist denn eure Meinung zu der Titel-Historie an Spieler und Mannschaften?

Mittlerweile ist dieses Thema nur noch eine Diskussion zwischen arminho, gmt und mir geworden. Haben andere User des Forums keine Meinung zu dem Thema oder den Daten, die gebraucht werden?

jetset

[Plotsch]

Doch abslout, ich verfolge die Debatte mit großen Interesse, bin aber zwischenzeitlich inhaltlich etwas ausgestiegen.

UNterstütze Jetsets Vorschlag aber absolut (sowohl Master-DB als auch importieren von Mannschaften, Spieler/Trainer, Stadien, Schiedsrichter).

MfG

Plotsch 

[tanne]

Ich lese dies auch mit großem Interesse und würde mir eine Importfunktion wünschen. Aber da ich mit Nicht-Web-DB-fähigen Frauen-Datenbanken beschäftige, habe ich mich bisher zurückgehalten.

Dennoch ein Beispiel: Bei der Erstellung einer Datenbank mit deutschen Länderspielen können die Spiele aus den int. Turnieren aus den schon vorhanden DBs übernommen werden. Den meisten Aufwand macht das Erfassen der Spieler für einen kompletten Kader bisher nicht vorhandener Mannschaften, bei einer WM sind das dierekt 6-7 Gegner mit jeweils mehr als 20 Spielern, also durchaus mehr als 100 Personen.

Bei solchen Mengen bringt es wenig, wenn man jeweils jede einzelne Person selektieren muss, sondern man sollte einen kompletten Kader selektieren und gemeinsam importieren können.

Wichtig ist dann eine Funktion, dass man für die Importmenge einen darauf beschränkten Dublettenabgleich durchführen kann, z.B. dadurch, dass man der Importmenge ein Zusatzkennzeichen mitgibt, dass im Dublettensuchverfahren gezielt gefiltert und nach dem Prüfen gelöscht werden kann.

Wenn sich aus der Diskussion und einer evtl. anschl. Umsetzung etwas ergibt, das auch für meine nicht-Web-DB-Datenbanken und nicht-Web-DB-Quellen (außer Stadien) etwas bringen würde, wäre dies schön.

Vielleicht könnte eine solche Importfunktion auch so aussehen, dass man damit Daten in eigenen Datenbanken gegen Daten in anderen (Web)-Datenbanken gegenprüfen könnte (also ein datenbankenübergreifendes Dublettensuchverfahren) und dadurch die eigene Datenbank um schon vorhandene Informationen verbessert. Der Import würde in diesem Fall eine Dublettenersetzung beinhalten. Dazu wären die zu importierenden Spieler mit den schon vorhandenen Spielern vor dem Import zu verknüpfen.

Wenn dies mit dem Vorrang der Infos aus den Web-DBs konsequent durchgeführt wird, ist dies schon eine Vorbereitung einer Nicht-Web-DB auf eine evtl. spätere Aufnahme in die Web-DB, weil es keine Dubletten mehr zur Web-DB gibt.

[champion]

Ich lese hier auch so nebenbei mit.

Eine Importfunktion würde ich gut finden. Nur WEB-DB-Spieler,Stadien würden ausreichen.

Ein Einzelimport ist für mich ausreichend.(Mecklenburg-Vorpommern, Australien)

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.

Na ja meist steigt nur eines oder 2 Teams aus Web-DB-Ligen in untere Ligen ab und oft sind dass dann auch die Teams die ein paar Saisons früher aufgestiegen sind und teilweise schon vorhanden sind. (Manche geben ja auch Landespokalwettbewerbe ein.)

Bei der Klub WM ist es sicherlich etwas Arbeit, aber so ein großes Problem ist das nun auch wieder nicht. Der Import allein ist doch schon eine große Erweiterung. Es dauert da mindestens genauso  lange die Spieler neu anzulegen für die Kader ,als wenn ich sie aus einer Master-DB laden würde.

Was ist denn eure Meinung zu der Titel-Historie an Spieler und Mannschaften?

Also das würde ich ganz interessant finden. Es wäre schön, dass wenn man Spieler X in die eigene Mannschaft importiert, auch gleich die Titel mit den zugehörigen Mannschaften importiert werden.

Wenn dies mit dem Vorrang der Infos aus den Web-DBs konsequent durchgeführt wird, ist dies schon eine Vorbereitung einer Nicht-Web-DB auf eine evtl. spätere Aufnahme in die Web-DB, weil es keine Dubletten mehr zur Web-DB gibt.

Stimmt.
Vielleicht werden dann ja mal viel mehr DBs zu Live-Update-DBs,  das ist glaube ich für viele Nutzer (nicht DB-Ersteller) wesentlich atraktiver weil es doppelt so schnell geht, als sich die Nutzer die DBs immer jede Woche neu downloaden.
Ich gebe auch zu das ich einige DBs öfter nutzen würde wenn sie Live-Update hätten.

[GMT]

Ist das richtig, dass die WEB-DB von den DB-Erstellern der Live-Update-fähigen DBs gepflegt wird?

Ja.
Jeder hat dort seinen ID-Bereich und alle Objekte einer (Web)DB gibt es auch in der WebDB.

Kann eine DB ohne Saison angelegt werden?

Nein.
Aber das ist unwesentlich, man kann ja eine Ein-Spiel-Saison eingeben ...

Ich würde auch die "Master-DB" zusammen stellen bzw. pflegen.

Zusammenstellen kann sie jeder, indem er sämtliche (Web)DB zusammenführt und dort bis auf eine alle Ligen löscht.

Wie würdest Du sie pflegen wollen?
Aktualisieren kannst Du sie ausschließlich durch erneutes Zusammenführen sämtlichr (Web)DB ...

In dieser Master-DB brauchen wir doch nur folgende Objekte:

• Mannschaften
  
• Spieler
  
• Schiedsrichter
  
• Stadien
  

Spiele und Saisons werden meiner Meinung nicht gebraucht. Was ist denn eure Meinung zu der Titel-Historie an Spieler und Mannschaften?

Richtig.


Dann will ich mal noch ein bißchen mehr an Futter für die Diskussion liefern.

• Eine "feste" Master-DB kann nicht so aktuell sein wie die WebDB. Sie wird zu irgendeinem Zeitpunkt X erstellt und bleibt dann auf diesem Datenstand.
  Die Daten in der WebDB werden jedoch laufend geändert, es finden sich trotz aller Mühe immer wieder Dubletten. Wer kann sicherstellen, daß - für den Moment eine feste und irgendwo zum Download bereitstehende Master-DB vorausgesetzt - daß nicht jemand heute einen Spieler importiert, den es seit vorgestern in der WebDB nicht mehr gibt? Er wurde als Dublette zu einem anderen identifiziert und dementsprechend gelöscht.
  
  
  
• Eine durch den Nutzer selbst zu erstellende Master-DB entschärft das Aktualitätsproblem deutlich, ist aber meiner Auffassung nach nicht erforderlich. Ich könnte die Objekte mühelos auch direkt aus einer konkreten (Web)DB ziehen. Der Kader eines Absteigers z.B. findet sich halt konkret in der DB zur Liga - zu welchem (Web)DB-Ersteller das Objekt gehört, spielt dabei gar keine Rolle.
  
  
  
• Würde durch die Vorgabe eines festen Quell-Dateinamens eine Master-DB "erzwungen", wäre nichts eingespart außer dem bereits existierenden Datei-Öffnen-Dialog. Es würde aber das gezielte Abfragen einer DB ohne Manipulationen verhindert. Was bringt das?
  Um es klarzustellen: Ich bin nicht gegen eine Master-DB, ich bin gegen den Zwang.
  Wer den arminho-Beispiel-Nigerianer sucht, wird durch eine existierende Möglichkeit der Einzel-DB-Abfrage nicht gehindert, sich eine Master-DB zu erzeugen und diese abzufragen.
  Daher könnten wir die Diskussion um eine Master-DB eigentlich völlig fallenlassen - wer eine will, legt sich eine an - wer nicht will, halt nicht.
  Und vergeßt nicht, daß eine Master-DB mit ihrem großen Datenbestand auch heftig Speicher frißt und entsprechend träge reagiert.
  Wer sich den Unterschied mal vor Augen führen will, vergleicht z.B. die MNE-Datenbank (zwangsweise ganz wenig Saisons) mit der DFS.vmd. Spielerverwaltung öffnen und dann "Alle" anklicken. Viel Spaß!
  
  
  
• Was wir von vornherein ausschließen können - so zumindest meine ich Volker zu kennen - sind irgendwelche Zusatzfelder oder Datenmanipulationen beim Massenimport.
  Was meine ich damit?
  tanne schrieb oben

  dass man der Importmenge ein Zusatzkennzeichen mitgibt, dass im Dublettensuchverfahren gezielt gefiltert

  Das geht nur über ein zusätzliches Datenbankfeld oder eine Datenmanipulation wie etwa eine an den Namen angehängte Kenn-Zeichenkette.
  Einerseits ist das unpraktisch - es hätten ja nur die importierten Spieler eine Kennung. Nicht aber die möglichen Dubletten.
  Glaubt mir, ich habe schon oft verzweifelt Spieler in meiner DB gesucht, die ich gerade eben erst importiert hatte. Und sie nur über die ID wiederfinden können.
  Mal ist da ein Vorsatzwort mit im Namensfeld, dann haben wieder Spanier/Portugiesen/Brasilianer usf. die wunderschönsten Wechselspiele mit ihren Künstlernamen getrieben ...
  Daß (Web)DB-Original und lokale Dublette also in der Liste nebeneinanderstehen ist überhaupt nicht sicher.
  
  Bis vor einem Jahr habe war ich derjenige, die WebDB regelmäßig mit den verschiedenstens Varianten auf Dubletten kontrolliert und immer etliche Dutzend gefunden hat.
  Wer solche Spiele schon mal massenweise getrieben hat wird mir zustimmen: Die Gefahr des Übersehens von Dubletten ist da immens; die reine "Pärchenbildung" der Dublettensuchfunktion im Studio läßt da noch zu viel durchgehen.
  
  Andererseits würde eine Datenmanipulation, die Kenn-Zeichenkette also, im Zweifelsfall Informationen vernichten. Dann nämlich, wenn der Name von sich aus schon die Maximallänge hat und das Kennzeichen dadurch Namensteile überschreiben muß.
  
  
  
• Wir wollen hier bitte nicht vergessen, daß für die oben von mir aufgelisteten Fälle der Import aus einer (Web)DB im Optimalfall einfach nur das Neuanlegen eines Objektes ersetzt. Dabei hat der Übernehmende den Vorteil, kein Geburtsdatum, Nationalspielerstatus, Nationalität und ggf. Zweitnationalität mehr recherchieren bzw. überprüfen zu müssen, sondern zuverlässige Daten frei haus zu bekommen.
  Für mich zumindest ist das bisher immer Grund genug gewesen, den Einzelimport als absolut ausreichend zu betrachten und über einen Massenimport nicht mal nachzudenken.
  Mein Vorgehen dabei habe ich in Antwort #26 beschrieben.
  
  Selbst wenn mal im Einzelfall der zusätzliche Aufwand den eben genannten Nutzen übersteigen sollte, gibt es ja noch weiteren Nutzen in Form der einheitlichen ID/GID ...
  
  
  
• Worin liegt der Vorteil eines Einzelimports beim nachträglichen Übernehmen von WebDB-Objekten?
  Beispiel: A.S. möchte in der SuperCup-DB die Spieler von Zenit und CSKA Moskva mit ihren WebDB-ID haben, damit er meine öffentlichen Bildchen nutzen kann.
  Er nimmt meine DB her, schreibt sich die ID zu den Spielern heraus - zu finden konzentriert in den Mannschaftskader der Vereine. Er muß also nicht suchen.
  Jetzt importiert er sich über eine Einzelfunktion Spieler ID 1.400.254 und fügt ihn sofort in den Mannschaftskader von Zenit ein.
  Und in diesem Moment wird es für den Dublettenabgleich völlig gleichgültig, ob der Typ nun in der SuperCup-DB bisher Archavine (französische Umschrift), Arschawin oder (korrekt) Arshavin heißt - bei den 18 Gestalten im Kader ist das noch schön übersichtlich, da sind (im Kader) nicht sooo viele Datensätze dazwischen.
  Und sogar das Geburtsdatum dürfte lokal falsch sein - wir wissen ja aufgrund der Kaderzugehörigkeit, daß es sich um denselben Spieler handeln muß.
  
  
  

[jetset]

• Eine "feste" Master-DB kann nicht so aktuell sein wie die WebDB. Sie wird zu irgendeinem Zeitpunkt X erstellt und bleibt dann auf diesem Datenstand.
  Die Daten in der WebDB werden jedoch laufend geändert, es finden sich trotz aller Mühe immer wieder Dubletten. Wer kann sicherstellen, daß - für den Moment eine feste und irgendwo zum Download bereitstehende Master-DB vorausgesetzt - daß nicht jemand heute einen Spieler importiert, den es seit vorgestern in der WebDB nicht mehr gibt? Er wurde als Dublette zu einem anderen identifiziert und dementsprechend gelöscht.
  

Änderung von Mannschaften:

• Ubennung des Vereins
  
• Fusion mit einem anderen Verein
  
• Auflösung und Neugründung
  

Änderungen von Spieler, Schiedsrichtern:

• Heirat
  
• Änderung von Künstlernamen
  

Änderungen von Stadioen:

• Namensänderung
  
• Kapazitätsanderung
  

Änderung von Kadern:

• Sommertransfers
  
• Wintertransfers
  

Reicht dann nicht eine Aktualisierung zum Saisonstart und nach der Winterpause?

• Eine durch den Nutzer selbst zu erstellende Master-DB entschärft das Aktualitätsproblem deutlich, ist aber meiner Auffassung nach nicht erforderlich. Ich könnte die Objekte mühelos auch direkt aus einer konkreten (Web)DB ziehen. Der Kader eines Absteigers z.B. findet sich halt konkret in der DB zur Liga - zu welchem (Web)DB-Ersteller das Objekt gehört, spielt dabei gar keine Rolle.
  

Keinen Zugriff auf die WEB-DB waren wir der Meinung wegen des hohen Trafficaufkommens.

• Würde durch die Vorgabe eines festen Quell-Dateinamens eine Master-DB "erzwungen", wäre nichts eingespart außer dem bereits existierenden Datei-Öffnen-Dialog. Es würde aber das gezielte Abfragen einer DB ohne Manipulationen verhindert. Was bringt das?
  Um es klarzustellen: Ich bin nicht gegen eine Master-DB, ich bin gegen den Zwang.
  Wer den arminho-Beispiel-Nigerianer sucht, wird durch eine existierende Möglichkeit der Einzel-DB-Abfrage nicht gehindert, sich eine Master-DB zu erzeugen und diese abzufragen.
  Daher könnten wir die Diskussion um eine Master-DB eigentlich völlig fallenlassen - wer eine will, legt sich eine an - wer nicht will, halt nicht.
  Und vergeßt nicht, daß eine Master-DB mit ihrem großen Datenbestand auch heftig Speicher frißt und entsprechend träge reagiert.
  Wer sich den Unterschied mal vor Augen führen will, vergleicht z.B. die MNE-Datenbank (zwangsweise ganz wenig Saisons) mit der DFS.vmd. Spielerverwaltung öffnen und dann "Alle" anklicken. Viel Spaß!
  

Okay eingeschränkt bist du natürlich in dem Namen der MasterDB und der Öffnen Dialog fällt weg, aber sonst ändert sich doch nichts am Importverfahren.

Ich habe mal spaßeshalber eine MasterDB aus den einzelnen existierenden WEB-DBs erstellt.
Inhalt:

• Mannschaften
  
• Spieler
  
• Schiedsrichter
  
• Stadien
  

Größe ca. 16 MB: Geschwindigkeit sehr träge

Was wir von vornherein ausschließen können - so zumindest meine ich Volker zu kennen - sind irgendwelche Zusatzfelder oder Datenmanipulationen beim Massenimport.

Datenmanipulation kommt für mich nur in der Ziel-DB in Frage. Vorausgesetzt, dass die Daten der Quell-DB korrekt sind und sich von den Daten in Ziel-DB unterscheiden(sprich Korrektur der Schreibweise, Korrektur des Geburtstages, Korrektur des Gründungsjahres, etc...).

[GMT]

Datenmanipulation kommt für mich nur in der Ziel-DB in Frage. Vorausgesetzt, dass die Daten der Quell-DB korrekt sind und sich von den Daten in Ziel-DB unterscheiden(sprich Korrektur der Schreibweise, Korrektur des Geburtstages, Korrektur des Gründungsjahres, etc...).

Mit Datenmanipulationen meinte ich das Anfügen einer Kennung in ein für andere Informationen vorgesehenes Feld.
Das kommt nicht infrage.
Weder in der Quell- noch in der Ziel-DB.

Ein zusätzliches Datenbankfeld nur für diese Kennung auch nur in der Ziel-DB geht ebenso nicht.

Und das Ganze vor dem Hintergrund, daß das Dublettenfinden danach auch im günstigsten Falle nur nervtötend ist. Im ungünstigsten findest Du nicht alle.


Mit Datenänderungen meinte ich in erster Linie Dubletten, die wir in der WebDB beseitigen.