Open Registry of Game Information 

  • prototypisches Datenmodell

  • Alles für Entwickler: Java, JavaScript, REST-API, AngularJS, HTML.
Alles für Entwickler: Java, JavaScript, REST-API, AngularJS, HTML.

Moderators: MZ per X, gene

 #35778  by gene
 29 Dec 2011, 07:14
zum Thema Mehrsprachigkeit:

Die Trennung zwischen Interface- und Daten-Sprache ist klar. Ich meinte wie beschrieben hier die Probleme beim *Daten*modell und daher auch bei der *Daten*-Sprache :D
Erstmal "nur" deutsch und englisch zu unterstützen finde ich OK. Sollten wir aber vernünftig vorsehen, daher fällt für mich die Variante "hart im Modell kodieren" weg. Für mich kommt hier nur eine allgemeingültige Lösung in Frage, damit wir später wie du schon andeutest keine Probleme beim Hinzufügen weiterer Daten-Sprachen haben. Ich überlege mir da mal eine Lösung. Ist aber ein sehr generelles Modellierungs-Problem.
Kann mir aber schon gut vorstellen, dass zu einzelnen Einträgen zunächst nur ein deutscher oder nur ein englischer Text vorhanden ist, und dass wir dann in der Web-Oberfläche recht einfach einen Button "weitere Sprache hinzufügen" einblenden können.

Beschreibungen zu Screenshots behalten wir dann bei, hast mich überzeugt 8)
 #35796  by MZ per X
 02 Jan 2012, 22:51
gene wrote:Kann mir aber schon gut vorstellen, dass zu einzelnen Einträgen zunächst nur ein deutscher oder nur ein englischer Text vorhanden ist, und dass wir dann in der Web-Oberfläche recht einfach einen Button "weitere Sprache hinzufügen" einblenden können.
Genauso stelle ich mir das vor. Aber wie schon gesagt muss natürlich jede weitere Datensprache durch die Community abgedeckt sein, das ist das Wichtigste.
gene wrote:Beschreibungen zu Screenshots behalten wir dann bei, hast mich überzeugt 8)
Puh, da fällt mir aber ein Stein vom Herzen. :D
 #35861  by wingi
 15 Jan 2012, 18:59
Ein paar Gedanken nach dem durchlesen des Datenmodell threads:

Ihr besprecht hier ein Datenmodell (ich nenne es mal Verwaltungsdatenstruktur), welches vollständig normalisiert sein sollte und universell alle Aspekte aller Einträge abbilden muß. Das ist richtig, aber:

1. Quellennachweis

Im Missionstatement wird der Quellennachweis für jeden Input angemerkt. Das passt in eine Verwaltungsdatenstruktur nicht hinein und wird ja von neueren Einträgen sogar überschrieben.

Auch wird noch nicht der Status eines Supports angesprochen. Also ob ein neuer Datensatz valide ist und in die globale Datenbasis eingebunden werden kann.

2. Webdatenbank

Die Datenbasis für die öffentliche Webseite hat ein anderes Ziel als die Verwaltungsdatenstruktur. Sie soll leicht durchsuchbar sein und auch schnelleren Zugriff bieten. Nicht jeder Datensatz muß deswegen komplett aus-normalisiert sein. Ein Produzent / Entwickler /Firma kann direkt im Datensatz stehen statt als Referenz auf die jeweilige Tabelle,

--------------------
Ich stelle mir folgende Schritte vor:

1. Wenn ein neuer Datensatz eingegeben wird, wird dieser auf Grund vieler Kategorien / Vorschläge ja schon grob einsortiert. Er enthält z.B. noch creation_date, author, check_state und ist ein flacher Datensatz. Das gilt auch für Bilder, welcher in diesem Schritt noch das Original gespeichert wird.

z.B. Bild eines Spiels + Titel + System + Sprache

2. Der Datensatz wird dann vom einem Admin / Mod überprüft und in die große Verwaltungsstruktur eingebunden. Es kann dadurch vorkommen, das vier Datensätze den Produzent als GameForge, zwei als GameFarce ausweisen. Jetzt kann der Admin / Mod zwei Datensätze als falsch markieren (damit werden diese nicht mehr importiert) oder aber eine zweite Version definieren.

z.B. Bild wird als Titelbild für die deutsche Spieleversion einsortiert (englisch war schon vorhanden) und auf einheitliches Format (300dpi) konvertiert.

Dieser Schritt wird der mit dem höchsten Softwareaufwand sein, da so aus flachen Eingabedatensätzen das Datenmodell gefüllt wird.

3. Aus den überprüften und hierarchisch einsortierten Datensätzen sollen Spieleeinträge für die Webseite generiert werden. Diese können z.B. die Normalisierung (Verweis auf Extratabelle) auf Hersteller verlieren und wieder halbwegs flach abgelegt werden. Das hilft auch bei der Nutzung in der Webprogrammierung.

Das Bild wir hier z.B. als Default-Titelbild genutzt, wenn es auf der deutschen Seite angezeigt (hier sogar webtypisch kleiner) wird.

------------------------------------
Weiterer Vorteil der drei "Datenversionen": Jede kann getrennt weiterentwicklet/benutzt werden. Aus den Eingabedatensätze kann statt manueller Arbeit auch ein Programm Einsortierungen vornehmen (Hersteller vergleichen usw.). Die dritte Variante (eindeutige, aber vollständige Datensätze pro Spielvariante) könnte dann als offene Datenbank rausgegeben werden.

So, Abendbrot ruft,

Christian Harms.
 #35865  by MZ per X
 15 Jan 2012, 20:54
Hi Christian!
wingi wrote:Ein paar Gedanken nach dem durchlesen des Datenmodell threads:
Wunderbar, dass Du gleich voll einsteigst! :) Ich bin kein großer Techie, aber ich habe ein paar Fragen/Kommentare zu Deinen Anmerkungen.
wingi wrote:Im Missionstatement wird der Quellennachweis für jeden Input angemerkt. Das passt in eine Verwaltungsdatenstruktur nicht hinein und wird ja von neueren Einträgen sogar überschrieben.
Der Quellennachweis bedeutet schlicht, dass wir zu jedem Support ein/mehrere Bilddateien und/oder Text dazuspeichern müssen, um die Herkunft der Daten für die Zukunft zu belegen. Ein späteres Überschreiben eines einmal freigeschalteten Supports sehe ich aber nicht zielführend, höchstens einen Änderungs-Support mit eigenem Quellennachweis.
wingi wrote:Auch wird noch nicht der Status eines Supports angesprochen. Also ob ein neuer Datensatz valide ist und in die globale Datenbasis eingebunden werden kann.
Ich denke ja laienhaft, dass die technische Validierung eines Datensatzes mittels vorgefertigten Formularen erfolgt, die fachliche Validierung später durch den Mod/Approver.

Bei MobyGames ist es so, dass Supports zwischen Contributor und Approver mit Kommentaren hin- und hergeschossen werden können, bevor die Freischaltung durch den Approver erfolgt. Ein nicht freigeschalteter Support ist öffentlich nicht sichtbar. Wir müssen zunächst mal organisatorisch klären, wie ein neuer Support auf der Website erscheinen soll: Öffentlich, aber unapproved? Oder erstmal versteckt bis zur Freischaltung? Oder mit Differenzierung anhand der Erfahrung des contributors (Punktzahl)? Das sollten wir aber in einem eigenen Thread tun.
wingi wrote:Weiterer Vorteil der drei "Datenversionen": Jede kann getrennt weiterentwicklet/benutzt werden. Aus den Eingabedatensätze kann statt manueller Arbeit auch ein Programm Einsortierungen vornehmen (Hersteller vergleichen usw.). Die dritte Variante (eindeutige, aber vollständige Datensätze pro Spielvariante) könnte dann als offene Datenbank rausgegeben werden.
Wie oben gesagt denke ich, dass ein frisch supporteter Datensatz bereits durch aus der Datenbank generierte Eingabeformulare technisch "perfekt" (also sofort speicherbar) sein sollte. Oder verstehe ich die drei Datenversionen einfach nur falsch? :)
 #35868  by gene
 15 Jan 2012, 22:35
Ihr seid ja super, da fahre ich morgen früh einmal in den Urlaub und ihr fangt solche Diskussionen an 8)

Dieser Vorschlag mit dem "Flachklopfen der Daten" für bessere Durchsuchbarkeit und schnellen Zugriff gefällt mir nicht.

Ich habe (beruflich) die Erfahrung gemacht, dass Anpassungen an das Datenmodell aus Performance-Gründen - wenn überhaupt - erst dann durchgeführt werden, wenn man merkt, dass die Performance eben nicht ausreichend ist. Ansonsten dient das - einzige - Datenmodell sowohl für die Dateneingabe-Phase als auch für die langfristige Speicherung, Suche und Anzeige.
Natürlich fehlt im Datenmodell bisher noch die Zuordnung zu User-Vorgängen, zu Zeitpunkten, die Historien usw. Es fehlt auch noch eine Regelung für die Dateneingabe, die meiner Meinung nach in der gleichen Datenstruktur (oder in einer "Doppelung") gespeichert werden müssen. Die (teilweise) Übertragung dieser Daten in den "echten" Daten-Bestand ist dann wirklich etwas Kompliziertes, was durch die Anwendung möglich sein muss. Du (wingi) sprichst da schon ein paar gute Beispiele an für die konkreten Anforderungen an das System. Diese Anforderungen müssen wir unbedingt (in einem separaten) Thread erarbeiten, um dann daraus eine technische Lösung abzuleiten bzw. entwickeln zu können.

Ich werde das in den nächsten Wochen mal anstoßen, indem ich die Problematik (mit grafischer Unterstützung) erkläre und dann an uns alle die Fragen stelle nach den konkreten Anforderungen.
 #35873  by wingi
 16 Jan 2012, 21:22
N'abend,

auch wenn gene im Urlaub ist, läßt sich weiter diskutieren.

Der Quellennachweis bedeutet ...
Meine Idee dahinter ist folgendes: Ein Spiel A existiert in der DB. Wir bekommen eine Erweiterung eines Datensatzes in Form eines Attributes (z.B. neues Titelbild + Beschreibung). Das wird vom Supporter akzeptiert und als Default-Bild gespeichert. Jetzt kommt die nächste Anfrage (1 Jahr später), das genau dieses Bild geklaut ist und die Quellenangabe nicht stimmt (sollte überprüfbar sein). Wir werden jetzt die Änderung rückgängig machen (Titelbild löschen). Können wir jetzt die alte Version des Titelbildes wiederherstellen?

Es geht nicht nur um den Quellenhinweis, sondern auch um eine Historie und der Wiederherstellung. So könnte z.B. eine initiale Befüllung der Datenbank durch eine "Datenspende" uns viel helfen, aber nachträglich wieder entzogen werden (Datenspende war nicht legal) und alle Supports auf den Datensätzen damit auch verloren gehen.

Eine andere Möglichkeit besteht, das man z.B. unterschiedliche Schreibweisen eines Firmennamens auf einen einheitlichen mappen kann und dann nachträglich verschiedene Spiele (mit Hilfe des Mappings) zusammen führen kann.

Wie das Freischalten / Sichtbarkeit von Supports passiert, was moderiert werden muß oder per Voting der Nutzer als "Ok" markiert wird, ist wirklich erstmal eine organisatorische Angelegenheit (und dann technisch). Ich würde beim Einsammeln der Daten darauf achten, das dadurch nicht die Datenbasis (unwiederbringbar) verändert wird (nur ein Backup wäre zu global). Ich schaue mir aktuell die Datenbankstruktur an, ob diese Idee im sinnvollen Umfang abbildbar ist.

Flachklopfen der Datenstruktur
Der Punkt des schnelleren Zugriffs ist nur einer - eine Suche kann auch ohne DB (Stichwort Volltextsuchmaschine) erledigt werden. Aktuell wird ein Datenbankdesign erstellt, welches alle Aspekte der Versionen / Abhängigkeiten usw. abbilden muß. Aber nicht all diese Daten sind für die letzt-endliche Webseite relevant. Und ich vermute, das die eigentlichen Daten sich später nur wenig ändern (z.B. Herstellerliste von Sega Mega Drive Spielen) und keine dynamischen Abfragen mehr erfordern. Aktuell würde die einfache Abfrage eines Spiels mehrere Tabellen per JOIN zusammenziehen - was nicht notwendig ist.

In der ersten Entwicklungsphase brauchen wir wahrscheinlich nicht zwischen Verwaltungsdatenbank und Webdatenbank unterscheiden. Ich arbeitete z.B. an einem Projekt mit einer Produktsuche, deren Daten einmal nachts exportiert und verteilt werden. Damit kann an der Datenbasis mit z.B. noch nicht freigeschalteten Datensätzen administrativ gearbeitet werden, und parallel die "fertigen" Daten für die Websuche benutzt werden. Ein Fehler in der Moderationssoftware kann damit nicht (sofort) die Webseiten-Daten löschen.

Anderer Grund: Eine (wahrscheinliche) Erweiterung der Verwaltungsstruktur muß dann nicht automatisch auf die Software der Webseite durchschlagen. Vielleicht ist die Anpassung erstmal nur notwendig, um eine neue Variante / Abhängigkeit abzubilden. Diese wird aber erst später öffentlich genutzt.

Gruß, Christian.
 #35890  by gene
 20 Jan 2012, 23:14
So, bin wieder da :D
... Historie der Daten und Dateien ...
Der Hinweis auf die "Historie" der hinterlegten Dateien ist ein guter Hinweis. Ich hatte bisher "nur" die Historien der eingegebenen textuellen und Verknüpfenden Informationen (Alles bis auf Dateien halt) im Kopf bei meinen Ideen. Aber du hast natürlich Recht, auch die jemals hochgeladenen Dateien dürfen durch Nichts endgültig gelöscht werden. Fehleingaben (bzw. Fehl-Aktionen) können immer passieren und dürfen keine Sackgassen zur Folge haben.
Trotzdem oder generell unabhängig davon bin ich nach wie vor der Meinung, dass man die Historien aller beteiligten Informationen und auch den "Vorschlags- oder Einreich-Charakter" nicht konkret modellieren sollte. Wir machen wirklich nur ein rein fachliches Modell mit Informationen über Spiele und Alles drumherum. Unser System muss dann natürlich den Anwender dabei unterstützen bzw. garantieren, dass Historien nicht verloren gehen und dass bestimmte Informationen einen "noch-nicht-freigeschaltet-Status" besitzen. Welche Konsequenz letzteres hat, ist noch festzulegen (keine oder eingeschränkte Anzeige).
... Beschleunigung der Suche und/oder Abstraktion der Suche/Suchdaten ...
Die Abstraktion der Suche und/oder der zu durchsuchenden Daten vom "operationalen Datenmodell" ist ebenfalls ein guter Hinweis. Denn natürlich soll der Programmcode für die Suche nicht ständig angepasst werden müssen. Aber ich bin auch hier nach wie vor der Meinung, dass diese Dinge keinen Einfluss auf das zentrale Datenmodell haben dürfen.

Um oft angefragte Daten nicht immer wieder neu zu erzeugen bzw. zu ermitteln, können wir später auch so etwas wie Squid vor den Webserver schalten. Ist meiner Meinung nach eine Sache, die die Architektur des System abdecken sollte und das solltenw ir nicht selber programmieren. Damit geht dann sowas wie das von dir beschriebene "Suchdaten sind stabiler als live eingegebene Daten" nicht mehr (so einfach).
 #35981  by gene
 24 Mar 2012, 23:51
Hatte heute die folgende, nette Idee:
Ich werde für zunächst die prototypisch umzusetztenden Spiele (siehe hier) per Programmcode mit Daten befüllen. Das bedeutet, dass ich die bekannten Veröffentlichungen etc. per Programmcode "live" aufbaue, damit man für diese Spiele dann eine Web-Darstellung aufrufen kann.

Und jetzt das "neue": Damit wir uns zunächst noch darauf konzentrieren können, ob das Datenmodell so funktioniert, werde ich eine Darstellungsform wählen, die eben nicht einer typischen Webseite entspricht, sondern einfach eine "Baum-Darstellung" verwenden.
Dafür werde ich JSTree verwenden, mit passenden Icons sollte das dann auch ziemlich einleuchtend sein!

Seid gespannt :D
 #35987  by MZ per X
 28 Mar 2012, 06:56
gene wrote:Oh - muss eben erstmal mein neues Macbook AIr einrichten... 8) 8)
Hey! Apple ist das neue Microsoft. :D
 #35990  by Independent
 28 Mar 2012, 14:23
Apple? Naja eine firmal die vorhandenes vernünftigt verknüpft und vollig überteuert auf den markt schmeißt. Heist nicht das die produkte schlecht sind aber ich mag den laden ganz und gar nicht.

PS: Am sonntag sind meine beiden platten abgeraucht und der lüfter vom prozzi ist an einer stelle abgebrochen. Ich schwitze immer noch mit dem kopieren der daten auf die neue platte.

@Gene: Du machst das schon so lange ich mit mein win7 alles machen kann.