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

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