03.02.2009, 08:48
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.
Und hier die Prämissen, die in der weiteren Diskussion zu berücksichtigen sind:[b]
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??
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.
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.
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.
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??