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

[Gabor70]

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.

Um mal, bei dem von jetset ins Spiel geworfenen, Ronaldo zu bleiben.
Was passiert denn, wenn ich Ronaldo importiere (bei mitgelierferten Anhängseln wie Stadien usw.) dann bekomme ich doch wohl oder übel diese Stadien UND Vereine mit, oder? Wenn ja, müsste ich dann nicht auch andere Objekte, die diesen "mitgelieferten" Daten (Spieler usw (und dann deren "Anhängsel")) anhängen nicht auch mitbekommen?
Wenn ja, dann brauchen wir hier gar nicht weiter über die "Mitlieferung" diskutieren, sondern dann geht es "nur" um den Import der Stammdaten.

Ich frage deshalb, weil ich mich in diesen technischen Machbarkeiten nicht auskenne.

[bignike]

Es gibt müssten 2 Möglichkeiten beim Importieren,
(welche durch eine Check-Box oder Einstellung) geben

Spieler A von der Bundesliga DB importieren (dh ID und GID)

a)mit

oder

b)ohne

Titel/Meisterschaft "nachsichziehen".


Bei der Variante a)wird du bei Oliver Kahn auch die Vereine Bayern München und KSC mitnehmen, sowie deren Stadien.

Bei der Variante b) würde nur die GID geändert.

[Gabor70]

Es gibt müssten 2 Möglichkeiten beim Importieren,
(welche durch eine Check-Box oder Einstellung) geben

Spieler A von der Bundesliga DB importieren (dh ID und GID)

a)mit

oder

b)ohne

Titel/Meisterschaft "nachsichziehen".


Bei der Variante a)wird du bei Oliver Kahn auch die Vereine Bayern München und KSC mitnehmen, sowie deren Stadien.

Bei der Variante b) würde nur die GID geändert.

Wobei Variante A wohl nur beim erstellen einer neuen DB genutzt werden würde, aufgrund des Dubletten-Problems, und das wohl auch nur beim ersten Objekt. Ich würde definitiv nur Variante B benutzen.

[chrisi]

[quote author=bignike link=topic=18668.msg131910#msg131910 date=1231172608]
Es gibt müssten 2 Möglichkeiten beim Importieren,
(welche durch eine Check-Box oder Einstellung) geben

Spieler A von der Bundesliga DB importieren (dh ID und GID)

a)mit

oder

b)ohne

Titel/Meisterschaft "nachsichziehen".


Bei der Variante a)wird du bei Oliver Kahn auch die Vereine Bayern München und KSC mitnehmen, sowie deren Stadien.

Bei der Variante b) würde nur die GID geändert.

Wobei Variante A wohl nur beim erstellen einer neuen DB genutzt werden würde, aufgrund des Dubletten-Problems, und das wohl auch nur beim ersten Objekt. Ich würde definitiv nur Variante B benutzen.
[/quote]

Ich finde, das kann man so nicht sagen. Wenn Oliver Kahn jetzt (nur als Beispiel) als Trainer nach GRE kommt und ich ihn dort importieren wolle, würde ich durchaus Variante b) benutzen, da ich weder Bayern noch Karlsruhe noch irgendwelche derer Stadien in meiner DB habe also keine Dublettengefahr besteht.

[bignike]

Einen Dublettenabgleich müsste es aber für jede mögliche Sache geben

Stadion
Mannschaft
Spieler/Trainer
Schiedsrichter

(wobei die letzten beiden schon programmiert und im Programm enthalten sind).

Dann könnte man die Variante "mit Nachziehen" einbauen.

Die Dublettensuche müsste dann aber von Hand durchgeführt werden, nicht das 2x die Allianz Arena eingetragen ist.

[jetset]

Hallo,

ich finde, dass wir das wie noch nicht ausreichend diskutiertiert haben !

Es sind hier 2 Möglichkeiten genannt worden:

• Eingabe von IDs und Import
  
• Auswahl des Objekts aus einem Dialog
  

Wird der Import aus den einzelnen Objekt- (Stadion, Mannschaft, etc) Verwaltung aufgerufen oder wird unter Datei als eigener Punkt aufgeführt und von dort gestartet?

Wie werden die IDs an die entsprechende Quelldatenbank übermittelt?

Wenn ein Auswahldialog angeboten wird, wie kommen die Daten in den Dialog?

Dann haben wir noch das Problem, dass nur eine DB mit dem DFS geöffnet werden kann

Jetzt sind die Daten im Speicher. Wie öffnen wir die Zieldatenbank ohne Datenverlust?

Also kurz gesagt, es sind noch einige technische Probleme, die wir haben.

Meine Frage dazu: Können wir uns mit dem Datentransfer an das LiveUpdate anlehnen?
Da sind jetzt diejenigen gefragt, die in dieser Thematik den Durchblick haben.

jetset

[Gabor70]

Es sind hier 2 Möglichkeiten genannt worden:

• Eingabe von IDs und Import
  
• Auswahl des Objekts aus einem Dialog
  

Wird der Import aus den einzelnen Objekt- (Stadion, Mannschaft, etc) Verwaltung aufgerufen oder wird unter Datei als eigener Punkt aufgeführt und von dort gestartet?

Wie werden die IDs an die entsprechende Quelldatenbank übermittelt?

Wenn ein Auswahldialog angeboten wird, wie kommen die Daten in den Dialog?

Dann haben wir noch das Problem, dass nur eine DB mit dem DFS geöffnet werden kann

Jetzt sind die Daten im Speicher. Wie öffnen wir die Zieldatenbank ohne Datenverlust?

Ich hatte heute die Idee im Kopf, dass man die Import-Funktion in den einzelnen Objekt-Verwaltungen einbauen könnte.

Beispiel: Ich möchte einen "falschen" Verein durch einen "richtigen" ersetzen. Dann geh ich in die Mannschaftsverwaltung, dort markiere ich den betreffenden Verein und klicke dann auf die noch zu erstellende Option ersetzen. Das öffnet mir dann eine Auswahlbox, in der ich die betreffende DB auswählen kann, in der der Verein vorhanden ist. Wenn ich dann die DB ausgewählt habe, müsste es eine Art Liste geben, in der die Objekte aufgeführt werden. Aus diesen Objekten wählt man dann das entsprechende aus und und bestätigt dann die Sicherheitsabfrage ob man denn auch wirklich das vorhandene Objekt ersetzen will. Hier könnte man jetzt auch noch eine Reihe von anderen Abfragen einbauen, wie z.B. ob man die Anhängsel mitgeliefert bekommen möchte oder nicht.
Damit hätte man auch gleich die Übernahme vorhandener Daten geregelt.

Hört sich einfach an, aber wie dann allerdings die technische Machbarkeit aussieht, weiss ich auch nicht. :-[

[GMT]

Wenn ja, müsste ich dann nicht auch andere Objekte, die diesen "mitgelieferten" Daten (Spieler usw (und dann deren "Anhängsel")) anhängen nicht auch mitbekommen?
Wenn ja, dann brauchen wir hier gar nicht weiter über die "Mitlieferung" diskutieren, sondern dann geht es "nur" um den Import der Stammdaten.

Ich frage deshalb, weil ich mich in diesen technischen Machbarkeiten nicht auskenne.

Nein, das Ganze ist nicht rekursiv.

Beim Import eines Objektes aus der WebDB in meine DB bekomme ich alle die Objekte zusätzlich zum eigentlich ausgewählten mit, die in der Verwaltung meines Objekttyps mit anderen verknüpft werden.

In der Mannschaftsverwaltung werden Titel und Stadien mit der Mannschaft verknüpft. Die kommen also alle beim Mannschaftsimport mit.

Mehr nicht.

Bei Spielern kommen alle Mannschafts- und persönlichen Titel mit.
Auch hier Sonderfall: Die Spielerverwaltung ist eine Sammelfunktion, in der gleichzeitig auch Kader verwaltet werden. Die Kaderverwaltungs-Daten (sprich: die Zuordnung des Spielers zum Kader) kommen beim Import nicht mit.

Sonderfall: Titel - die haben keine eigene, separate Verwaltung und kommen nur über die Mannschaftsverwaltung in die DB. Kein Titel ohne Mannschaft.

Daher hier diese Kette: Spieler zieht Titel zieht Mannschaft zieht Stadion. Da ist dann aber Schluß.


Beim Import aus der WebDB in eine (Web)DB ist das kein Problem. Wir sind nahe am Ideal der Dublettenfreiheit.

[GMT]

Bei der Variante b) würde nur die GID geändert.

Falsch:
ID + GID + Name + Vorsatzwort + Vorname + Geburtsdatum + Nationalität(en) + Nationalspierstatus.

[bignike]

[quote author=bignike link=topic=18668.msg131910#msg131910 date=1231172608]
Bei der Variante b) würde nur die GID geändert.

Falsch:
ID + GID + Name + Vorsatzwort + Vorname + Geburtsdatum + Nationalität(en) + Nationalspierstatus.
[/quote]

Nun das meinte ich auch, einfach OHNE Nachziehen der Mannschaften und Titel

[GMT]

Nun das meinte ich auch, einfach OHNE Nachziehen der Mannschaften und Titel

Nimm' es mir nicht übel, aber was Du meinst, solltest Du auch sagen.
Möglichst korrekt formuliert.

[GMT]

Wie werden die IDs an die entsprechende Quelldatenbank übermittelt?
Wenn ein Auswahldialog angeboten wird, wie kommen die Daten in den Dialog?

Dann haben wir noch das Problem, dass nur eine DB mit dem DFS geöffnet werden kann

Jetzt sind die Daten im Speicher. Wie öffnen wir die Zieldatenbank ohne Datenverlust?

Also kurz gesagt, es sind noch einige technische Probleme, die wir haben.

Ich merke schon, Du liest hier wirklich gründlich mit.  ;D

Ganz klar: Es gibt nur eine Möglichkeit, die Datenfremdverwaltung auszuschließen: Diese Daten dürfen nicht irgendwo extern abgelegt werden. Auch nicht im Hauptspeicher des PC.

Außerdem muß sichergestellt werden, daß die Ziel-DB beim unvorhergesehen Aktionen nicht zerschossen wird. Also erfolgt jede einzelne Aktion unmittelbar in der DB auf der Platte.
(Im Unterschied z.B. zur Textverarbeitung, in der man bei entsprechenden Einstellungen stundenlang Texte bearbeiten kann ohne Sicherung. Wenn dann irgendwo die Stromsicherung 'rausfliegt ...)

Die Möglichkeit des Datenimportes aus einer anderen DB in die aktuell geöffnete innerhalb des Studios gibt es bereits - DB zusammenführen nutzt genau das. Dabei wird die zweite DB sozusagen im Hintergrund geöffnet. Du selbst kannst sie dabei nicht öffnen, nicht auswerten, nicht abfragen - gar nichts.

Daher habe ich keinen Zweifel, daß Volker hier etwa ein neues Rad erfinden wird.

Meine Frage dazu: Können wir uns mit dem Datentransfer an das LiveUpdate anlehnen?

Ich nehme an, Du meinst nicht LU, sondern die entsprechenden Funktionen für (Web)DB-Ersteller?

Wenn ja: Darauf arbeite ich die ganze Zeit hin.

[GMT]

Ich hatte heute die Idee im Kopf, dass man die Import-Funktion in den einzelnen Objekt-Verwaltungen einbauen könnte.

Sehr gut!  O0

Da gehören sie tatsächlich hin.

Hört sich einfach an, aber wie dann allerdings die technische Machbarkeit aussieht, weiss ich auch nicht. :-[

Eben aus diesem Grund - und aus den in meinem vorigen Beitrag genannten - bleibt eigentlich nur die von mir weit oben genannte Möglichkeit, sich die benötigten ID aus einer DB herauszuschreiben und dann die Objekte einzeln über die ID aus der im Hintergrund zu öffnenden Quelle herauszuziehen.
Völlig unabhängig davon, was genau nun diese Quelle ist. (Sicherheitssatz.  : Diese Diskussion ist jetzt noch nicht dran.)


Und denkt bitte nicht, daß ich hier etwas zusammenspinne:
Wenn ich mir z.B. demnächst den aktuellen (realen) Kader von Stuttgart bei den Spielen gegen Zenit aus der WebDB hole, mache ich als erstes die DFS.vmd auf und nehme mir die ID der konkreten Spieler von dort, also aus dem "Studio-Kader". Schon deshalb, weil ich 100% sicher sein kann, daß ich dann den richtigen Elson oder Cacau habe und nicht irgendeinen anderen, der vielleicht unter demselben Künstlernamen irgendwann mal in Portugal gespielt hat.

[GMT]

Dann könnte man die Variante "mit Nachziehen" einbauen.

Die Dublettensuche müsste dann aber von Hand durchgeführt werden, nicht das 2x die Allianz Arena eingetragen ist.

Genau das halte ich für problematisch: Niemand von uns kann sich von vornherein für einen Kader drei Stunden Zeit reservieren.

Wenn Du Dir vornimmst, mal eben 20 Spieler eines Kaders zu importieren - Anwendungsbeispiel: den Kader von Rubin Kazan aus der RUS-DB in die CL-DB, fällig im September 2009 - hast Du gewisse Zeitvorstellungen. Kommen dann in so einem Fall bei einem Spieler die oben erwähnten 35 Zusatzobjekte mit, dürfte Dein Zeitplan ins Trudeln geraten.

Es sei denn, Du verschiebst die Dublettensuche auf später - mit allen denkbaren Folgen.

Daher hielte ich es für besser, das Nachziehen von Informationen völlig wegzulassen und statt Dublettenabgleich ein reines "Stammdatenabgleichen" wie oben beschrieben durchzuführen.

Dies entspricht dem oben klar formulierten Zweck des Vorschlages, in dem von einer vollständigen Übernahme aller Informationen zum Spieler nicht die Rede war.
Da ging es nur um einheitliche Stammdaten.

[chrisi]

[quote author=Gabor70 link=topic=18668.msg131927#msg131927 date=1231187384]
Hört sich einfach an, aber wie dann allerdings die technische Machbarkeit aussieht, weiss ich auch nicht. :-[

Eben aus diesem Grund - und aus den in meinem vorigen Beitrag genannten - bleibt eigentlich nur die von mir weit oben genannte Möglichkeit, sich die benötigten ID aus einer DB herauszuschreiben und dann die Objekte einzeln über die ID aus der im Hintergrund zu öffnenden Quelle herauszuziehen.
[/quote]

Kleiner Einschub: Es gibt für MyMedia ja bereits ein Clipboard, so etwas könnte man doch hier ebenfalls einführen und sich dann die benötigten Spieler aufs Clipboard packen, sodass das Studio die IDs in der gewünschten DB erkennt. So hätte man wieder ein wenig Zeit gespart. ^-^

[Plotsch]

Ich muss zugeben dass ich den technischen Faden mal wieder verloren habe  >...

ist ja auch nicht so wichtig, dafür gibt es andere Experten.

Mir stellt sich allerdings im Moment die entscheidende Frage nach dem Mehrwert der diskutierten importfunktion (unter Berücksichtigung der Dinge die alle NICHT gehen).

Ursprünglich waren ja zwei Gründe als Mehrwert einer solchen Funktion debatiert worden:

1. Vereinheitlichung der (Stamm)Daten und
2. Erleichterung der Erstellung neuer Stammdatensätze (durch Import aus bestehenden DB's)

Nun sind in der Debatte zwei Sachen (aus technischen und andern Gründen) klargestellt geworden, zumindest wenn ich es richtig verstehe:
1. Es kann keinen Import von Stammdaten aus nicht WebDB's geben (das heißt de facto, dass sich der zu importierenden Datenbestand auf diese DB's beschränkt)
2. Es kann keinen Massenimport von Stammdaten geben, da dieser aufgrund der Dubletten- und Überschreibungsproblematik mehr als problematisch ist.

Vor diesem Hintergrund würde ich gerne noch einmal diskutiert wissen, wozu eine solche Importfunktion denn nun tatsächlich taugt und ob dieser Nutzen einen, wie mir scheint, sehr aufwendigen Programmiervorgang überhaupt rechtfertigt.

Selbstverständlich ist es schön, mal den einen oder anderen Import zu machen - Ronaldinho wechselt vom AC Mailand zu den Boca Juniors ;-) und ich könnte mir die Abtipparbeit sparen - wunderbar

Aber seien wir mal ehrlich, wie oft kommt so etwas schon vor? Gerade bei Spielern/Trainern wäre doch das suchen der entsprechenden Personen in den einzelnen Web DB's doch recht mühsam. 

Nehmen wir nur mal das von Chrisi angesprochene Beispiel und seine GRE-DB. Da kommen in der nächsten Saison 40 Spieler neu nach Griechenland. 30 kann er nach eingehendender Recherche  10 verschiedenen WebDB's zuordnen, 10 kommen dazu aus Arabien wieder nach Europa zurück, haben aber vorher in ENG und NED gespielt, was Chrisi im ersten Augenblick nicht bewusst ist. 

Dazu kommen noch drei Trainer neu dazu, die vor drei Jahren schon in Russland, der Ukraine und Deutschland trainiert haben zwischenzeitlich aber arbeitslos waren
(d.h. Sie sind in der Web DB vorhanden, aber eben auch nicht gleich zuzuordnen).

Ehe Chrisi gemerkt hat, welche Spieler und Trainer als Stammdaten in der Web DB angelegt sind und diese aus den einzelnen DB's importiert hat, sind die Daten abgetippt (Die Titelhistorie kann ja technisch sowieso nicht abgebildet werden).

Prinzipiell und gerade bei den internationalen DB's - von nichteuropäischen DB's will ich mal gar nicht sprechen - erscheint mir eine Importfunktion mehr als Sinnvoll (vor dem Hintergrund eines turbulenten Transfermarktes) um eine Daten-Vereinheitlichung und Arbeitserleichterung zu erreichen.

Wenn aber, aus sicherlich sehr guten Gründen, weder ein Massenimport, noch eine WebDB-unabhängige Lösung zustande kommt,  wird das Importieren zu einer netten Spielerei - nicht mehr. In der "tagtäglichen Arbeit" nur sehr bedingt hilfreich - was schade wäre.

Aber vielleicht habe ich den Nutzen der diskutierten Version bisher nur noch nicht richtig erkannt.

MfG

Plotsch

[jetset]

Hallo Plotsch,

wir haben bisher eindeutig das Ziel und den Zweck der Importfunktion diskutiert.

Jetzt diskutieren wir das wie die Daten importiert werden sollen.

Welche Daten und woher die Daten kommen wurde bisher noch nicht letztendlich diskutiert und geklärt.

Deine Einwände und Diskussionsansätze gehen aber nicht verloren (hoffe ich).

jetset

[Axel04]

Nehmen wir nur mal das von Chrisi angesprochene Beispiel und seine GRE-DB. Da kommen in der nächsten Saison 40 Spieler neu nach Griechenland. 30 kann er nach eingehendender Recherche  10 verschiedenen WebDB's zuordnen, 10 kommen dazu aus Arabien wieder nach Europa zurück, haben aber vorher in ENG und NED gespielt, was Chrisi im ersten Augenblick nicht bewusst ist. 

Auch wenn Plotsch hier jetzt an dem derzeitigen Kern der Diskussion vorbeigeht, muss ich leider sagen, dass ich mich an eben diesem Szenario auch ein wenig störe. Ich möchte zu bedenken geben, dass sich diverse DB-Ersteller von eben diesem Problem der Unübersichtlichkeit möglicherweise soweit abschrecken lassen könnten, dass sie die Funktion gar nicht erst nutzen (ich beziehe mich jetzt nicht im speziellen auf meine eigene DB). Nur dann würde das eigentliche Ziel der Qualitätsverbesserung/Vereinheitlichung der Nicht-Web-DBs im Sande verlaufen.

Zur eigentlichen Diskussion:
Ich würde eine Lösung ohne Mitziehen von Titeln deutlich bevorzugen. Am geeignetsten erscheint mir die Lösung des reinen Ersetzens der Stammdaten, wie es GMT weiter oben geschildert hat. Dass so z.B. auch eigene Notizen und Titeleinträge erhalten bleiben könnten, spielt sicher für DB-Ersteller die hier gerne ein wenig mehr herumwerkeln eine gewichtige Rolle.

[GMT]

Plotsch, Du hast völlig recht:
Nicht für jeden DB-Ersteller ist der Nutzen dieser Funktion für die tägliche Arbeit überragend.

Für den Nutzer eigener MyMedia-Archive dagegen schon.

Nützlich ist diese Funktion in erster Linie für "bereichsüberschneidende" DB.
Kallegeils FA-Cup-DB könnte auf die Daten der ENG-Ligen-DB zurückgreifen - und müßte dort nicht groß suchen: Sogar die Kader bekäme er frei haus. Schweizer Länderspiele auf die SUI-DB. Um nur mal zwei Beispiele aus dem Handgelenk zu schütteln.
Alle europäischen DB können z.B. auf die Nationalspieler aus der EM-DB zurückgreifen.

Was nicht unterschätzt werden darf: Immer wieder finde ich in den verschiedenen Datensammlungen unterschiedliche Geburtsdaten - nutze ich den WebDB-Spieler, muß ich mir keine bzw. weniger Gedanken machen, welches Datum konkret nun das richtige ist.
Im Zweifelsfall kann sogar die WebDB profitieren, wenn auf diese Weise ein Fehler dort festgestellt und korrigiert werden kann.

Von Schreibweisen vor allem von Künstlernamen wollen wir hier lieber schweigen.

Nun sind in der Debatte zwei Sachen (aus technischen und andern Gründen) klargestellt geworden, zumindest wenn ich es richtig verstehe:
1. Es kann keinen Import von Stammdaten aus nicht WebDB's geben (das heißt de facto, dass sich der zu importierenden Datenbestand auf diese DB's beschränkt)
2. Es kann keinen Massenimport von Stammdaten geben, da dieser aufgrund der Dubletten- und Überschreibungsproblematik mehr als problematisch ist.

Das verstehst Du richtig.

Vor diesem Hintergrund würde ich gerne noch einmal diskutiert wissen, wozu eine solche Importfunktion denn nun tatsächlich taugt und ob dieser Nutzen einen, wie mir scheint, sehr aufwendigen Programmiervorgang überhaupt rechtfertigt.

Ich schrieb oben bereits, daß ich in dieser Diskussion unter anderem auf die Annäherung an bestehende Funktionen für die Arbeit mit der WebDB hinsteuere.
Folge: Der Aufwand sollte für Volker beherrschbar bleiben, solange das hier Gewünschte existierende Rahmen nicht sprengt.

Das Hinsteuern (teilsweise: Das Bremsen von Vorschlags-Ausbau-Phantasien) tue ich auch vor dem Hintergrund, daß ich mit meinen regelmäßigen Importen von Objekten der UEFA-CL/UEFA-Cup-Gegener russischer Vereine sehr wohl weiß, wovon ich rede, was tatsächlich benötigt wird.

Und ich verkenne auch nicht, daß der Nutzen z.B. für Dich bei der ARG-DB eher klein ist.

[GMT]

Nur dann würde das eigentliche Ziel der Qualitätsverbesserung/Vereinheitlichung der Nicht-Web-DBs im Sande verlaufen.

Wenn Du damit meinst, daß alle Nicht-(Web)DB vereinheitlicht werden sollen - das war als Ziel so nie formuliert worden. Auch nicht mit der Einschränkung "dort, wo möglich".

Ganz klar ist, daß für verschiedene Ersteller der Nutzer einer solchen Funktion gering ist. Für andere bleiben Aufwand und Nutzen in einem so akzeptablen Verhältnis, daß sie auch ohne großen MyMedia-Enthusiasmus diese Funktion nutzen werden. Kallegeils z.B. dürfte sich bei konsequentem Kopieren und Einfügen etliche Stunden an Arbeit sparen können. Von Tippfehlern bzw. deren automatischer Vermeidung ganz zu schweigen.

Auch bei Dir sehe ich einen nicht zu unterschätzenden Nutzen zumindest für einen nennenswerten Teil der Vereine. All diejenigen, die Du aus den Landes-DB quasi übernehmen könntest.
Ebenso wie historische Angaben zu Schiedsrichtern auch nicht immer leicht zu finden sind.

[jetset]

[quote author=Plotsch link=topic=18668.msg131941#msg131941 date=1231193958]

Nehmen wir nur mal das von Chrisi angesprochene Beispiel und seine GRE-DB. Da kommen in der nächsten Saison 40 Spieler neu nach Griechenland. 30 kann er nach eingehendender Recherche  10 verschiedenen WebDB's zuordnen, 10 kommen dazu aus Arabien wieder nach Europa zurück, haben aber vorher in ENG und NED gespielt, was Chrisi im ersten Augenblick nicht bewusst ist. 

Auch wenn Plotsch hier jetzt an dem derzeitigen Kern der Diskussion vorbeigeht, muss ich leider sagen, dass ich mich an eben diesem Szenario auch ein wenig störe. Ich möchte zu bedenken geben, dass sich diverse DB-Ersteller von eben diesem Problem der Unübersichtlichkeit möglicherweise soweit abschrecken lassen könnten, dass sie die Funktion gar nicht erst nutzen (ich beziehe mich jetzt nicht im speziellen auf meine eigene DB). Nur dann würde das eigentliche Ziel der Qualitätsverbesserung/Vereinheitlichung der Nicht-Web-DBs im Sande verlaufen.

Zur eigentlichen Diskussion:
Ich würde eine Lösung ohne Mitziehen von Titeln deutlich bevorzugen. Am geeignetsten erscheint mir die Lösung des reinen Ersetzens der Stammdaten, wie es GMT weiter oben geschildert hat. Dass so z.B. auch eigene Notizen und Titeleinträge erhalten bleiben könnten, spielt sicher für DB-Ersteller die hier gerne ein wenig mehr herumwerkeln eine gewichtige Rolle.
[/quote]

Ich gebe hier zu bedenken, dass die Anlage der Titel eine Menge Arbeit ist und das ich bei einigen Spielern diverser DBs schon Ungereimtheiten bei den Titeln gefunden habe. (z.B. ein Spieler wurde mit 2 unterschiedlichen Vereinen im gleichen Jahr Meister)

Die Turnier(Pokal)-DB-Ersteller und DB-Ersteller, die noch Titel nachziehen wollen, profitieren am meisten vom Import.

jetset

[GMT]

Titel nachziehen stand meiner Erinnerung nach nicht im Zweck des Importes. 

Was glaubst Du, warum ich so bohrend danach gefragt habe? 

---

Zwei Meisterschaften in einem Jahr ist nicht prinzipiell unmöglich: Ein Spieler spielt die 1. Halbserie in der Meisterschaft eines Landes, die zweite in der Meisterschaft eines anderen. Beide Teams, in deren Kader er war, werden Meister. Also bekommt er nach den Studioregeln zwei Meistertitel in diesem Jahr.

Selbst wenn man die Teilnahme am letzten Spiel der Meisterschaft fordern würde, wäre das nicht ausgeschlossen: Im Mai wird ein Spieler z.B. deutscher Meister, im November russischer ...

---

Das Für und Wider des Nachziehens zusätzlicher Objekte oder Informationen habe ich ausführlich dargestellt.
Was schön wäre muß nicht machbar sein.
Obwohl ich das nicht in letzter Konsequenz auschließen will. Das kann nur Volker endgültig entscheiden.

Daher: Wollen wir das jetzt noch nachträglich in den Zweck als MUSS aufnehmen oder lieber nicht?

[jetset]

Titel nachziehen stand meiner Erinnerung nach nicht im Zweck des Importes. 

Die Diskussion der Titelhistorie hatten wir zurückgestellt.

Zwei Meisterschaften in einem Jahr ist nicht prinzipiell unmöglich: Ein Spieler spielt die 1. Halbserie in der Meisterschaft eines Landes, die zweite in der Meisterschaft eines anderen. Beide Teams, in deren Kader er war, werden Meister. Also bekommt er nach den Studioregeln zwei Meistertitel in diesem Jahr.

Der Spieler war die gesamte Saison aber nicht mehr im Kader der einen Mannschaft  :'(

Das Für und Wider des Nachziehens zusätzlicher Objekte oder Informationen habe ich ausführlich dargestellt.
Was schön wäre muß nicht machbar sein.
Obwohl ich das nicht in letzter Konsequenz auschließen will. Das kann nur Volker endgültig entscheiden.

Daher: Wollen wir das jetzt noch nachträglich in den Zweck als MUSS aufnehmen oder lieber nicht?

Das können wir doch bei der Diskussion über das Was importiert werden soll diskutieren.

[Plotsch]

Für den Nutzer eigener MyMedia-Archive dagegen schon.

Bei neu angelegten Spielern/Trainern/Vereinen mag dieser Nutzen da sein, beim überschreiben vorhandener Stammdaten eher nicht (zumindest wenn es sich um einen eifrigen MyMedia-Nutzer handelt).

Nehmen wir ein fiktives Beispiel:
DB Ersteller A importiert aus der NED-DB für eine (schon vorhandene, gepflegte und mit MyMedia-Daten versehene) NED-Pokal-DB etliche Spieler, Trainer und Vereine. Seine "alten" ID's werden überschrieben. Damit ist der "Kontakt" zu seinen bisherigen MyMedia-Dateien unterbrochen und die Darstellung "seines" MyMedia-Archivs nicht mehr gegeben. Um diesen wiederherzustellen, müsste er relativ mühsam seine XML-Datei mit den neuen ID's anpassen. Bei 200 oder 300 Spieler kann das relativ arbeitsintensiv werden (vor allem wenn man sich die Mühe schon mal ein paar Monate vorher gemacht hatte.)

Bitte korrigiert mich wenn ich hier irre.

Dieser Punkt ist in meinen Augen sehr wichtig. Der muss unbedingt im Sinne aller MyMedia-Ersteller zufriedenstellend geklärt werden.

Nützlich ist diese Funktion in erster Linie für "bereichsüberschneidende" DB.
Kallegeils FA-Cup-DB könnte auf die Daten der ENG-Ligen-DB zurückgreifen - und müßte dort nicht groß suchen: Sogar die Kader bekäme er frei haus.

Ich glaube hier liegt ein Denkfehler vor.

Denn es gibt, zumindest in meinen Augen, ein paar Grundsätze die alle DB's prägen und die bei der Erstellung der Spieler wichtig sind.

1. Die meisten DB's sind "reife" DB's mit einem gewachsenen Fundus an Stammdaten.
2. Spieler entwicklen sich von unten nach oben

Was bedeutet dass? 
1. Dass viele Spieler schon jetzt in den DB's aufgelistet sind (weil es die meisten ja schon eine Weile gibt) und somit die Zahl der möglichen "Neu"-Importe begrenzt ist. Außerdem muss der Zeitpunkt beachtet werden, ab wann ein Spieler "gebraucht" wird.
Beispiel FA-Cup: Kallegeils muss ja heute schon die meisten Vereine/Trainer/Spieler aus ENG in seiner DB haben. Sicherlich könnte er zukünftig auf die Kadererstellung aus den Ligen-DB's warten und diese dann vollständig importieren. Dann würde er aber auf obiges Problem stossen, wenn er eine MyMedia-Archiv hat.

2. Dass Spieler zuerst in den "unteren" DB's erfasst werden müssen (aus der Natur der Sache, weil eben die wenigsten Spieler qua Geburt bei Chelsea spielen), bevor Sie aus einer
"höheren" DB importiert werden können.
Beispiel EM-DB: die Norwegischen Nationalspieler tauchen mit Sicherheit zuerst in der Norwegen-DB auf bevor Sie in der EM-DB auftauchen - weil Sie in Norwegen eben zuerst als Stammdatensatz gebraucht werden (Ausnahmen bestätigen wie immer die Regel).

Das Hinsteuern (teilsweise: Das Bremsen von Vorschlags-Ausbau-Phantasien) tue ich auch vor dem Hintergrund, daß ich mit meinen regelmäßigen Importen von Objekten der UEFA-CL/UEFA-Cup-Gegener russischer Vereine sehr wohl weiß, wovon ich rede, was tatsächlich benötigt wird.

Unabhängig von den oben beschriebenen Problemen ist der Komfort der Importfunktion, also das  suchen, finden und importieren von Stammdaten aus der WebDB heraus, die zentrale Schlüsselstelle.

Vielleicht kann ja mal einer der WebDB-Ersteller schildern wie dieser Vorgang im Moment vonstatten geht, damit man sich ein Bild davon machen. IN meinen Augen würde das helfen.   

Und ich verkenne auch nicht, daß der Nutzen z.B. für Dich bei der ARG-DB eher klein ist.

Das ist schon OK. Vielleicht gibt es ja in Zukunft mal einen WebDB-Ersteller, der den nord- und südamerikanischen Kontinent bearbeitet, dann kann man daran anknüpfen. Sollte es beim importieren eine nach Ländern geordnete Importfunktion geben, würde ich mir übrigens alle argentinischen Spieler/Trainer aus der WebDB importieren ;-)...

MfG
Plotsch

[jetset]

Bei neu angelegten Spielern/Trainern/Vereinen mag dieser Nutzen da sein, beim überschreiben vorhandener Stammdaten eher nicht (zumindest wenn es sich um einen eifrigen MyMedia-Nutzer handelt).

Nehmen wir ein fiktives Beispiel:
DB Ersteller A importiert aus der NED-DB für eine (schon vorhandene, gepflegte und mit MyMedia-Daten versehene) NED-Pokal-DB etliche Spieler, Trainer und Vereine. Seine "alten" ID's werden überschrieben. Damit ist der "Kontakt" zu seinen bisherigen MyMedia-Dateien unterbrochen und die Darstellung "seines" MyMedia-Archivs nicht mehr gegeben. Um diesen wiederherzustellen, müsste er relativ mühsam seine XML-Datei mit den neuen ID's anpassen. Bei 200 oder 300 Spieler kann das relativ arbeitsintensiv werden (vor allem wenn man sich die Mühe schon mal ein paar Monate vorher gemacht hatte.)

Bitte korrigiert mich wenn ich hier irre.

Nein, Plotsch. Beim Import wird nichts überschrieben. Also schon angelegte Daten bleiben erhalten, die dann im 2. Schritt abgeglichen werden sollten.

Kleiner Tipp: Vor dem Import die VMD-Datei sichern.

Was bedeutet dass? 
1. Dass viele Spieler schon jetzt in den DB's aufgelistet sind (weil es die meisten ja schon eine Weile gibt) und somit die Zahl der möglichen "Neu"-Importe begrenzt ist. Außerdem muss der Zeitpunkt beachtet werden, ab wann ein Spieler "gebraucht" wird.
Beispiel FA-Cup: Kallegeils muss ja heute schon die meisten Vereine/Trainer/Spieler aus ENG in seiner DB haben. Sicherlich könnte er zukünftig auf die Kadererstellung aus den Ligen-DB's warten und diese dann vollständig importieren. Dann würde er aber auf obiges Problem stossen, wenn er eine MyMedia-Archiv hat.

2. Dass Spieler zuerst in den "unteren" DB's erfasst werden müssen (aus der Natur der Sache, weil eben die wenigsten Spieler qua Geburt bei Chelsea spielen), bevor Sie aus einer
"höheren" DB importiert werden können.
Beispiel EM-DB: die Norwegischen Nationalspieler tauchen mit Sicherheit zuerst in der Norwegen-DB auf bevor Sie in der EM-DB auftauchen - weil Sie in Norwegen eben zuerst als Stammdatensatz gebraucht werden (Ausnahmen bestätigen wie immer die Regel).

zu 1)  Es kann dann auch über den Import und Dublettenabgleich Spieler aktualisiert werden.
zu 2) Wechselt ein Spieler von Chelsea zu Real (noch nie in Spanien gespielt) so ist es doch eine Importfunktion doch von Vorteil und der Spieler ist nicht in den unteren DBs. Und ausserdem wurde ja mit den oberen Ligen und den aktuellen Saisons begonnen. So viele untere Ligen gibt es ja noch nicht.

Vielleicht kann ja mal einer der WebDB-Ersteller schildern wie dieser Vorgang im Moment vonstatten geht, damit man sich ein Bild davon machen. IN meinen Augen würde das helfen.   

GMT hat schon mal in einem der vorherigen Beiträgen das Verfahren grob angeschnitten.

Das ist schon OK. Vielleicht gibt es ja in Zukunft mal einen WebDB-Ersteller, der den nord- und südamerikanischen Kontinent bearbeitet, dann kann man daran anknüpfen. Sollte es beim importieren eine nach Ländern geordnete Importfunktion geben, würde ich mir übrigens alle argentinischen Spieler/Trainer aus der WebDB importieren ;-)...

Da haben wir das Problem schon:

Aus der WM-DB könntest du dir schon die Nationalspieler importieren, aber der Import aus der Copa America DB würde dann nicht gehen, da Nicht(Web)DB zu Nicht(Web)DB der Import ja nicht konzipiert und durchgeführt werden soll.  :'(

MfG
jetset

[GMT]

Bei neu angelegten Spielern/Trainern/Vereinen mag dieser Nutzen da sein, beim überschreiben vorhandener Stammdaten eher nicht (zumindest wenn es sich um einen eifrigen MyMedia-Nutzer handelt).

Richtig. Eine Vereinheitlichung wird es aber nur auf Grundlage der WebDB und deren ID geben können.

Etwas allen recht getan ...

Ich glaube hier liegt ein Denkfehler vor.

Denn es gibt, zumindest in meinen Augen, ein paar Grundsätze die alle DB's prägen und die bei der Erstellung der Spieler wichtig sind.

1. Die meisten DB's sind "reife" DB's mit einem gewachsenen Fundus an Stammdaten.
2. Spieler entwicklen sich von unten nach oben

Liegt nicht vor.

Das ist von vornherein - ich deutete das oben schon an - eine Funktion, die nicht allen Nutzen bringen kann.

So wie nicht jeder Nutzer oder gar jeder DB-Ersteller MyMedia-Archive selbst anlegen kann und/oder will - gibt es diese Funktion, wird sie nicht jeder nutzen.

Unabhängig von den oben beschriebenen Problemen ist der Komfort der Importfunktion, also das  suchen, finden und importieren von Stammdaten aus der WebDB heraus, die zentrale Schlüsselstelle.

:o  Wie kommst Du denn auf dieses schmale Brett? 

Es ging in dem Vorschlag noch an keiner einzigen Stelle um den Zugriff zur WebDB.

Vielmehr ging es hier immer um Zugriff auf lokal vorhandene (Web)DB, also solche Datenbanken, die von (Web)DB-Erstellern gepflegt werden und die die abgestimmte Datenbasis WebDB einerseits erzeugen und andererseits nutzen.

Vielleicht kann ja mal einer der WebDB-Ersteller schildern wie dieser Vorgang im Moment vonstatten geht, damit man sich ein Bild davon machen. IN meinen Augen würde das helfen.   

Den Teufel werden wir tun.

Es ist ja wohl allen klar, daß die (Web)DB-Ersteller zusätzliche Funktionen haben müssen, damit die Kommunikation mit der WebDB funktioniert.

Über diese Funktionen in der Öffentlichkeit zu schreiben ist aber Volkers Vorrecht.

GMT hat schon mal in einem der vorherigen Beiträgen das Verfahren grob angeschnitten.

Einer hat's gemerkt!  ;D

Das ist schon OK. Vielleicht gibt es ja in Zukunft mal einen WebDB-Ersteller, der den nord- und südamerikanischen Kontinent bearbeitet, dann kann man daran anknüpfen. Sollte es beim importieren eine nach Ländern geordnete Importfunktion geben, würde ich mir übrigens alle argentinischen Spieler/Trainer aus der WebDB importieren ;-)...

Oder Du wirst selbst mal irgendwann (Web)DB-Ersteller ...

[vmLOGIC]

Nach eurer intensiven Diskussion möchte ich mich jetzt auch mal wieder einschalten.
Einige Begriffsklärungen und verschiedene Prämissen halte ich für angebracht, damit anschließend zielgerichtet weiter überlegt werden kann, ob und wie der Vorschlag umgesetzt werden kann.


Zunächst ein paar Begriffe, wie ich sie verwende.
Dies nur, damit wir nicht aneinander vorbei reden. Denn in vorhergehenden Beiträgen war mir nicht immer klar, was der jeweilige Verfasser genau gemeint hat.
Beispiel: Den Begriff "(Web)DB" gibt es so nicht. Der Verfasser könnte damit die "WebDB" oder die "(Web)DB-fähigen Datenbanken" gemeint haben. Ein klitzekleiner Unterschied, der je nach persönlicher Interpretation des Begriffs völlig unterschiedliche Aussagen in die Beiträge bringt.

• WebDB
  Eine Datenbank, die sich auf meinem Server (sprich: im Web) befindet.
  Die WebDB ist zum einen der zentrale Ort, an dem (Web)DB-Ersteller ihre Datenobjekte wie Spieler/Trainer, Schiedsrichter, Mannschaften, Stadien usw. hinterlegen. Mit dem Ziel, jedes einzelne Datenobjekt nur einmal (ohne Dubletten) und aktuell (neuster Informationsstand) für die Verwendung von allen (Web)DB-Erstellern vorzuhalten.
  Zum anderen werden in der WebDB die Live-Update-Informationen gespeichert, die anschließend jedem Studio-Benutzer zur Verfügung stehen.
  Und der Vollständigkeit halber noch die Info, dass die WebDB keine Spiel-Datenbasis ist. Von temporären Live-Update-Daten mal abgesehen, weiß die WebDB nichts über Ligen, Spielpaarungen, Aufstellungen etc.
  
  
• (Web)DB-fähige Datenbank
  (Web)DB-fähige Datenbanken sind Studio-Datenbanken, die die (Web)DB als Datenbasis verwenden. Ein konkreter Spieler wird demnach in allen (Web)DB-fähigen Datenbanken mit der selben ID, mit der selben GID und mit identischen Stammdaten (Name, Geburtsdatum usw.) eingetragen sein.
  Um dies zu gewährleisten, bemühen sich die (Web)DB-Ersteller permanent darum, keine Dubletten zu erzeugen, vorhandene Dubletten aufzuspüren und zu eliminieren sowie den Informationsstand der ca. 100.000(!!) Datenobjekte sowohl in der WebDB als auch in den (Web)DB-fähigen Datenbanken aktuell zu halten.
  (Web)DB-fähige Datenbanken sind erkennbar am orangen Symbol in der Funktion "Nach Updates suchen".
  
  
• (Web)DB-Ersteller
  Es handelt sich hierbei um ein Kunstwort, das die Begriffe "DB-Ersteller" und "WebDB" kombiniert.
  (Web)DB-Ersteller pflegen - wie viele andere Benutzer - mindestens eine Studio-Datenbank. Sie sind also "DB-Ersteller".
  Mit dem kleinen Unterschied, dass sich (Web)DB-Ersteller zusätzlich um die recht zeitaufwändige Pflege der zentralen Datenbasis in der WebDB kümmern.
  
  
  

Und hier die Prämissen, die in der weiteren Diskussion zu berücksichtigen sind:[b]

• [b]Änderungen von Daten in der WebDB
  Die zentrale Datenbasis in der WebDB wird derzeit von insgesamt 15 fleißigen Personen gehegt und gepflegt. Hin und wieder kommen weitere (Web)DB-Ersteller hinzu.
  Man kann sich selbst als Außenstehender vorstellen, dass dies nur mit entsprechendem Engagement und Abstimmungsaufwand funktionieren kann.
  Um hier nicht die Kontrolle zu verlieren und die Aufwände nicht weiter zu erhöhen, sind und bleiben Änderungen der Daten in der WebDB den (Web)DB-Erstellern vorbehalten.
  
  
• Lesen von Daten aus der WebDB
  Nach längerer Überlegung bin ich zum Schluss gekommen, die WebDB auch für lesende Zugriffe nicht weiter zu öffnen.
  
  Zum einen ist es immer mal wieder erforderlich, dass kuddel oder ich in der WebDB Anpassungen vornehmen müssen. Dabei müssen wir höllisch aufpassen, dass keine unschönen Effekte entstehen. Sei es für die (Web)DB-Ersteller oder die Benutzer der Live-Updates.
  Mit den (Web)DB-Erstellern können wir die Konsequenzen abstimmen. Das funktioniert meistens. Abstimmungen mit Nutzern der Live-Updates sind nicht so einfach möglich. Daher können wir manche Änderungen nur machen, wenn quasi zeitgleich eine neue Studio-Version bereitgestellt wird.
  Eine zusätzliche Nutzergruppe, die entstehen würde bei Öffnung der WebDB zwecks Datenimport in eigene Datenbanken, würde die Möglichkeiten (und die Zeitfenster) von kuddel und mir noch weiter einschränken.
  
  Zum anderen ist die WebDB der mit weitem Abstand größte Kostenfaktor für mich. Letztlich sind es die Live-Updates, die an Wochenenden eine enorme Prozessorleistung erfordern und reichlich Traffic verursachen. Das setzt einen recht teuren dedizierten Server voraus.
  Eine erweiterte Nutzung der WebDB könnte u.U. dazu führen, dass auch die derzeitige Serverklasse nicht mehr ausreicht und meine Kosten dann wieder ansteigen. Zumindest könnte ich die Hoffnung begraben, in absehbarer Zeit auf einen etwas kleineren Server wechseln zu können, um so ein paar Euros einzusparen.
  
  
• Mein "NEIN" zur Erstellung einer Studio-DB, die alle Daten der WebDB enthält!
  Die Idee einer "quasi lokalen (Web)DB" ist in den vorhergehenden Beiträgen angesprochen worden.
  Ich habe oben bereits deutlich gemacht, dass die Pflege einer zentralen Datenbasis sowie deren Auswirkungen auf die angeschlossenen (Web)DB-fähigen Datenbanken für einige Leute mit reichlich Zeitaufwand verbunden ist.
  Für eine zweite zentrale Datenbasis fehlt dann aber jegliche Bereitschaft.
  
  
• Mein "NEIN" zum gleichzeitigen Öffnen mehrerer Studio-Datenbanken!
  Ich habe in den Anfängen der Programmierung des Studio nicht absehen können, dass sich das Interesse dafür so gewaltig entwickeln könnte. Somit auch nicht einen Vorschlag wie den, der hier zur Diskussion steht. Knapp 6 Jahre nach "Grundsteinlegung"!
  So bin ich immer davon ausgegangen, dass es keinen zwingenden Bedarf geben wird, mehr als eine Datenbank gleichzeitig zu öffnen.
  Ich selbst weiß aber, dass ich diese Restriktion nachträglich nicht eben per Fingerschnipp abschaffen kann. Und solange es keinen wirklich zwingenden Grund dafür gibt, werde ich das auch nicht tun.
  Fehler im Studio gibt es hin und wieder. Diese sind dann immer "nur unschön", können aber mit Ruhe behoben werden.
  Ich kann mich aber an keinen Fall erinnern, der dazu geführt hätte, dass Datenbanken wegen Fehlern im Studio krepiert sind. Der Super-Gau, wenn man keine Sicherung hat!
  Ich will nicht darüber nachdenken, welche Falltüren ich öffne, wenn ich die gleichzeitige Nutzung mehrerer Datenbanken unterstützen würde. Da liegt mir die Sicherheit eurer Daten doch zu sehr am Herzen, als dass ich hier fahrlässig werden könnte.
  Wer diese Restriktion mit irgendwelchen Tricks erfolgreich umgeht, der weiß dann hoffentlich was er tut. Das möglicherweise traurige Resultat mag er dann selbst verantworten.
  
  
  

Nachdem ich ...
1. Zugriffe auf die WebDB ausgeschlossen habe, ...
2. es auch keine lokal verfügbare Studio-DB geben wird, die sämtliche Daten aus der WebDB enthält ...
3. und auch das gleichzeitige Öffnen von mehr als einer Studio-Datenbank ausgeschlossen ist, ...
bleibt für den Vorschlag also bestenfalls der direkte Datenaustausch zwischen einzelnen Studio-DBs.
Einen solchen direkten Weg gibt es bereits beim Zusammenfassung von Datenbanken. Auch hier öffnet das Studio verschiedene Datenbanken "im Hintergrund", um Daten einzusammeln.

Wir können wir hier nun diskutieren, wie ein solcher Datenaustausch gestaltet werden kann.
Denn es macht keinen Sinn, den Vorschlag in einer Weise umzusetzen, die letztlich nur mit viel Aufwand für mich verbunden ist, letztlich aber wegen unzumutbarer Handhabung keine Akzeptanz findet.

Um hier ein sinnvolles Vorgehen zu entwickeln, muss klar sein, welche Ziele damit verfolgt werden. Welche die wirklich wichtigen sind. Und zwar unter Berücksichtigung der Prämissen, die ja möglicherweise schon dem ein oder anderen Ziel einen Riegel vorschieben.
Geht es vorrangig um GIDs (wegen MyMedia), dann könnte man möglicherweise eine "billige" Lösung andenken.
Geht es vorrangig um die Übernahme einzelner Datenobjekte aus (Web)DB-fähigen Datenbanken in die eigene DB, um möglicherweise die eigenen Datenobjekte anschließend per Dublettenkiller zu eliminieren, dann könnte dies auch noch mit einer einfachen Lösung machbar sein.
Wenn es um Massentransporte geht, dann sieht das schon anders aus. Zumindest dann, wenn die Auswahl dieser "Masse" vom Studio unterstützt werden soll.
Richtig kompliziert wird es dann, wenn wir beim Datenaustausch über mehr als die Stammdaten der einzelnen Datenobjekte reden. Wenn also auch die automatische Übernahme der abhängigen Daten wie Titel von Spielern usw. gefordert wird.


Jetzt seid ihr wieder am Zug!
Meinungen??

[jetset]

Nachdem ich ...
1. Zugriffe auf die WebDB ausgeschlossen habe, ...
2. es auch keine lokal verfügbare Studio-DB geben wird, die sämtliche Daten aus der WebDB enthält ...
3. und auch das gleichzeitige Öffnen von mehr als einer Studio-Datenbank ausgeschlossen ist, ...
bleibt für den Vorschlag also bestenfalls der direkte Datenaustausch zwischen einzelnen Studio-DBs.
Einen solchen direkten Weg gibt es bereits beim Zusammenfassung von Datenbanken. Auch hier öffnet das Studio verschiedene Datenbanken "im Hintergrund", um Daten einzusammeln.

Wir können wir hier nun diskutieren, wie ein solcher Datenaustausch gestaltet werden kann.
Denn es macht keinen Sinn, den Vorschlag in einer Weise umzusetzen, die letztlich nur mit viel Aufwand für mich verbunden ist, letztlich aber wegen unzumutbarer Handhabung keine Akzeptanz findet.

Um hier ein sinnvolles Vorgehen zu entwickeln, muss klar sein, welche Ziele damit verfolgt werden. Welche die wirklich wichtigen sind. Und zwar unter Berücksichtigung der Prämissen, die ja möglicherweise schon dem ein oder anderen Ziel einen Riegel vorschieben.
Geht es vorrangig um GIDs (wegen MyMedia), dann könnte man möglicherweise eine "billige" Lösung andenken.
Geht es vorrangig um die Übernahme einzelner Datenobjekte aus (Web)DB-fähigen Datenbanken in die eigene DB, um möglicherweise die eigenen Datenobjekte anschließend per Dublettenkiller zu eliminieren, dann könnte dies auch noch mit einer einfachen Lösung machbar sein.
Wenn es um Massentransporte geht, dann sieht das schon anders aus. Zumindest dann, wenn die Auswahl dieser "Masse" vom Studio unterstützt werden soll.
Richtig kompliziert wird es dann, wenn wir beim Datenaustausch über mehr als die Stammdaten der einzelnen Datenobjekte reden. Wenn also auch die automatische Übernahme der abhängigen Daten wie Titel von Spielern usw. gefordert wird.

Als ich den Vorschlag gemacht habe, dachte ich zuerst und vorangig an einen Import von Datenobjekten inklusive der GIDs, aber an die Nebeneffekte im Bereich MyMedia hatte ich dabei nicht gedacht. Vorrangig war das Ziel eine Vereinheitlichung der Datenobjekte in allen "neuen" DBs oder einer Korrektur in bestehenden DBs.

Jetzt nach monatelanger Diskussion und den Prämissen von Volker, denke ich, dass der Import auf einen Vorschlag von GMT  hinausläuft.

• Auswahl einer DB
  
• Auswahl eines Datenobjekts
  
• Eingabe der GID, die vorher manuell ermittelt wurde
  
• Importvorgang
  
• Dublettenabgleich
  

Die beschriebene Vorgehensweise funktioniert natürlich nur bei einzelnen Datenobjekten.


Wichtig ist auch hier die Überlegung, was alles importiert werden soll. Wird erst eine einfache Lösung des Datenaustauschs angestrebt, ohne abhängige Datenobjekte, dann wird über kurz oder lang die nächste Forderung zum Import anstehen.

Meine Idee zu den abhängigen Datenobjekte wäre, das die entsprechenden Stammdaten auch importiert werden können, und die Abhängigkeiten von jedem selbst hinzu gefügt werden kann. Somit kann jeder für sich entscheiden, ob er diese Daten haben möchte oder nicht.

Ist die GID ein eigenes Objekt?
Der Eindruck entsteht bei mir, weil immer von GID und Datenobjekt gesprochen wird. Ich bin immer davon ausgegangen, dass die GID Bestandteil des Datenobjekts ist und deshalb nie gezielt einen Import von GIDs gesprochen habe. Ich bin immer davon ausgegangen, wenn ich den Import eines Datenobjekts und den Dublettenabgleich durch geführt habe, habe ich auch die GIDs angeglichen.

• Wird eine Lösung des Imports auf der Grundlage des Zusammenführens einzelner DBs angestrebt, was ist dann mit den GIDs, die im öffentlichen Bereich liegen?
  
• Kann ich solche Datenobjekte dann importieren?
  
• Oder soll der Import von Datenobjekte auf Objekte im nicht öffentlichen Bereich beschränkt werden?
  
  

jetset

[vmLOGIC]

Wichtig ist auch hier die Überlegung, was alles importiert werden soll. Wird erst eine einfache Lösung des Datenaustauschs angestrebt, ohne abhängige Datenobjekte, dann wird über kurz oder lang die nächste Forderung zum Import anstehen.

Daher frage ich JETZT nach dem Mindestbedarf. Wenn viele sagen, dass das Ganze ohne abhängige Datenobjekte eh sinnlos wäre, dann würde ich den Aufwand genauer prüfen. Denke aber, dass ich dann vom Vorschlag insgesamt die Finger lassen werde.

Ist die GID ein eigenes Objekt?
Der Eindruck entsteht bei mir, weil immer von GID und Datenobjekt gesprochen wird. Ich bin immer davon ausgegangen, dass die GID Bestandteil des Datenobjekts ist und deshalb nie gezielt einen Import von GIDs gesprochen habe.

Nein, die GID ist kein Datenobjekt.
Wenn ich oben gefragt habe, ob evtl. "nur" die GIDs die wesentliche Motivation für den Vorschlag sind - du beschreibst das ja auch in deinem ersten Beitrag - dann wäre die Lösung weniger aufwändig.

Wird eine Lösung des Imports auf der Grundlage des Zusammenführens einzelner DBs angestrebt, was ist dann mit den GIDs, die im öffentlichen Bereich liegen? [/li][/list]

Nein. Hier würde ich keine Einschränkungen machen.

Kann ich solche Datenobjekte dann importieren?
Oder soll der Import von Datenobjekte auf Objekte im nicht öffentlichen Bereich beschränkt werden?

Aus allen DBs in jede andere solltest du importieren können.
Aus diesem Grund sollte die Anforderung auch (technisch) überschaubar bleiben.
Stichwort: Abhängige Datenobjekte!!


Was das Handling betrifft könnte mir eine Art "in den Warenkorb legen" vorstellen.
Man öffnet also irgendeine DB, legt die gewünschten Datenobjekte in den Warenkorb. Dann öffnet man noch ne DB und sammelt auch dort ein. Letztlich öffnet man die DB, in die die Datensätze rein sollen und "kippt dort den Warenkorb" aus.
Dies nur mal ganz spontan, ohne schon überlegt zu haben, was ich mir damit antue.

[tanne]

Hört sich doch gut an.

[chrisi]

Stimmt. Würde ich aber nur nutzen, wenn ich einen oder gleich mehrere komplette Kader brauche. Weil ich mir einfach nicht vorstellen kann, dass ich Zeit einspare, wenn ich einen Spieler in einer anderen DB suchen, hinzufüge, meine DB öffne und dort einfüge als wenn ich einfach bei tm.de den Spieler suche und die Daten abtippe. :

[tanne]

was ist tm.de ?

[silvermane]

transfermarkt

[vmLOGIC]

Nach vielen Diskussionen komme ich hier zum Schluss, dass es keine Lösung gibt, die...
1) ... einfach zu bedienen wäre,
2) ... sämtliche Wünsche erfüllen könnte,
3) ... vielen Benutzern helfen würde und
4) ... mit vertretbarem Aufwand zu programmieren wäre.

Ich befürchte hier zudem eine "never ending Story", sobald ich auch nur das kleinste Angebot machen würde.
Somit lege ich das Thema zu den Akten.