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

[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