Bevor wir zum Einrichten der Arbeitsumgebung kommen, ein paar inhaltliche Details.
In der Schiedsrichterverwaltung sollen die Daten aller Saisons aller Einsätze der Schiedsrichter verwaltet werden. Im Vordergrund steht erst einmal die Anzeige, dafür müssen grundsätzlich erst einmal die Daten erfasst werden. Die Verwaltung soll Teile der Daten und die Administration der Daten vor unbefugtem Zugriff schützen.
Folgende Daten fallen also an: Saisons, Ligen, Einsatzinformationen, Adressen, Schiedsrichter, Teams, Clubs, Kontaktdaten, Nutzer und die Änderungshistorie müssen verwaltet werden. Daraus ein DB-Schema zu erstellen, ist nicht schwierig, die Normalformen, die Vermeidung redundanter Daten und möglichst hohe Flexibilität machen das Ganze unübersichtlich.
Als zugrundeliegende DB-Engine bieten sich XML und MySQL an, einfach aus pragmatischen Gründen. MySQL ist bei meinem (eigentlich bei jedem) Hoster vorinstalliert und kann genutzt werden, XML ist von Hand editierbar und per PHP gut anzusprechen.
Ich habe mit dem XML-Schema begonnen (als DTD), ziemlich schnell aber wegen der Menge der Daten und ihren Beziehungen untereinander aufgegeben. Da modelliere ich lieber mit einem Werkzeug und setze auf eine Datenbank auf, nutze ein vorhandenes Framework und spare mir so viel Arbeit. XML ist zwar reizvoll, wird in der Praxis bei mir aber nur für kleine, überschaubare Datenmengen eingesetzt.
Als Modellierungswerkzeug nehme ich die MySQL Workbench, plattformübergreifend, einfach einzusetzen, übersichtlich und auf MySQL zugeschnitten.
Die derzeitige Datenbankstruktur sieht wie folgt aus (Klick zum Vergrößern):
Wer die aktuellste Version ansehen möchte oder die Workbench-Datei oder ein PDF bevorzugt, wird im git-Repository unter “database” fündig.
Zur Benennung: die Tabellen erhalten alle das Präfix “rfrmgr_”, so dass ich die Tabellen parallel zu anderen DB-Tabellen nutzen kann, ohne Namenskollisionen zu befürchten. Das ist wichtig, wenn nur eine DB zur Verfügung steht oder mein Plan verwirklicht wird, das irgendwie mit WordPress zu koppeln (was mit der Nutzerverwaltung haklig werden kann).
Die Tabellen selbst folgen den Namenskonventionen von CakePHP, keine Überraschung an dieser Stelle. Wichtig ist, auch die Fremdschlüssel den Konventionen entsprechend zu benennen, da Cake so die Beziehungen automatisch findet. Die Beziehungen zwischen den Tabellen, die ich modelliert habe, nutzt Cake nicht, diese sind zum Verständnis meinerseits gedacht.
Die zu erhebenden Daten, die Beziehungen etc. sind ein erster Aufschlag, der sich dann in der Praxis bewähren muss. Auch ein Test, wie schnell Änderungen an der DB durch das Framework eingebunden werden können. Insbesondere die Adressdatenverwaltung sieht mir noch so aus, als wenn sich da was ändern könnte. Aber ganz Rapid-Prototyping-artig will ich erst mal Ergebnisse sehen und dann verfeinern.
Das war’s zur Datenbank, in Bälde wird die Arbeitsumgebung eingerichtet (und dann noch einmal).
