Hallo,

ich habe in der letzten Zeit ein Spiel programmiert, um genau zu sein
einen Fussballmanager. Wie man sich nun vorstellen kann, fallen dabei
jede Menge Daten an, die gespeichert werden müssen. Ich habe mich für
die Firebird DB entschieden. Allerdings speichere ich meine Daten noch
sehr stümperhaft in der Datenbank ab!

Stümperhaft bedeutet: Für Spieler, Vereine,...usw. gibt es jeweils Tabellen
in denen die Daten als BLOBs gespeichert werden. Diese BLOBs
sind wiederum Ini-Files.

Den Weg über die Ini-Files habe ich gewählt, weil man damit sehr leicht
Daten übersichtlich speichern und lesen kann. Die Daten schreibe ich
automatisch mittels meiner RTTI Routine in die Ini-Files.

Dies alles und die große Datenmenge führen dazu, dass das Laden bzw. Speichern ewig dauert!

Mein Ziel ist es nun die Daten übersichtlich und erweiterbar abzuspeichern.
Jedoch musste ich bemerken, dass sich eine Relationale DB dafür nicht
wirklich anbietet, aufgrund sehr komplexer Verknüpfungen zwischen den Objekten.
Es würden folglich unzählige Schlüsselbeziehungen von Nöten werden, wobei
man total den Überblick verliert.

Das führte mich zu Objektorientierten Datenbanken und OPFs, mit denen man
solche Strukturen abspeichern kann.
Das Problem hierbei ist, dass es entweder keine kostenlosen Varianten gibt, oder
dass diese Komponenten auf die DB-Klassen von Delphi zurückgreifen, welche mir
in der Delphi 2005 Personal Edition fehlen.

Meine Frage ist nun, ob es vielleicht noch eine Möglichkeit gibt komplexe Strukturen
abzuspeichern? Oder wie ich was verbessern könnte?!

Hmmm.. Also generell ist, wie du schon festgestellt hast, das mit den INIs nicht das Gelbe vom Ei.


Allerdings kann ich mir auch nicht vorstellen, dass sich das ganze nicht in einer relationalen Datenbank abbilden lassen würde. Da kann man dir sicher helfen, wenn du ein paar mehr Infos verlauten lässt.

Ok, ich hab mal versucht meine Struktur graphisch darzustellen.
(Sollen keine UML-Diagramme sein! Der DBDesigner war nur gerade zur Stelle...)

Ich hab mich auch nur auf die Verknüpfungen zwischen allem
beschränkt und bewusst die Eigenschaften weggelassen.

Ich könnte notfalls auch meine Klassen preisgeben?!

Na ja, kein Problem:

Eine 1:n Beziehung kannst Du so implementieren (Master - 1:n -> Detail)
(Master.ID, Master.Data)

(Detail.ID, Detail.Master.ID, Detail.Data)

Jeder Detaildatensatz enthält also einen Verweis auf den Master. So hat jeder Master n Details, und jedes Detail genau 1 Master.

Eine m:n Beziehung geht über eine separate Tabelle:

(Master.ID, Master.Data)
(Detail.ID, Detail.Data)

(Relation.Master.ID, Relation.Detail.ID)

Jedes Detail hat m Master und jeder Master hat n Details)

Hi,

vielleicht auch sonst mal das hier oder das hier oder auch mal hier schauen, ob sich jemand schon die Mühe gemacht hat.

Was mir bei deinem ClubBild schon auffält...das kann man vereinfachen. Wenn du keine History der Trikots etc machen willst, dann kannst du die beiden Felder direkt dem Club zuordnen oder haben die mehr als 1 Heim- und Auswärtstrikot? Für den Präsidenten gilt das Gleiche.

Taktik ist eigentlich kein Attribut des Clubs, sondern des einzelnen Spiels. Was du mit der Cup und History Tabelle willst, weiß ich nicht. Denn in einer Datenbank könnte man so etwas mit Abfragen auflösen. Ich denke, dass man mit etwas Aufwand das Datenmodell verschlanken kann, was dann aber mit Sicherheit zu massiven Veränderungen in deinem Code führen wird.

Danke schonmal für die Tips.

@ene:
Die Trikots und den Presidenten habe ich auch bereits direkt in den Club eingebunden,
weil es auch mir unnötig erschien, dafür extra Tabellen/Listen anzulegen.
Es kam vielleicht nur nicht so gut in meiner Grafik rüber...

Die Taktik sollte ein Attribut des Clubs sein, weil diese nicht für jede Begegnung
abgespeichert werden soll und der Spieler diese auch nicht jedes mal neu festlegen
soll.

Die Historytabelle ist im Prinzip nur eine Auflistung der Erfolge nach folgendem Schema:
01.01.1899 | Weltpokal | Mannschaft A - Mannschaft B 1:0
die Einträge in der History sind vom Typ TCup (Datum, Wettbewerb, Kommentar).
-> das dürfte nicht wirklich ein Problem darstellen.

Dass ich jenes Datenmodell gewählt habe, hat den Grund, dass sich dieses nach unzähligen
Versuchen als das Beste für mich herausgestellt hat.
Es ist sicherlich nicht perfekt, aber für mich noch am logischsten.
Bin aber auch jederzeit für Verbesserungen offen.


@alzaimar
Das mit den Schlüsseln leuchtet mir ein. Meine große Befürchtung ist nur,
dass ich den Überblick dabei verliere.

Eine grundlegende Frage hätte ich allerdings noch:
Am Beispiel Wettbewerb: Jeder Wettbewerb hat Runden in denen Begegnungen festgelegt wurden.
Sollte man nun alle Begegnungen in einer großen Tabelle "Matches" abspeichern und auf
diese verweisen, oder lieber den Weg über viele kleinere Tabellen wählen (alá "DFBPokal.Runde1.Matches")?

Man könnte es auch mit einer Art SelfJoin machen. Am Anfang verteilt man GruppenID (Vorrunde) und danach hangelt man sich mit der MatchID weiter, so dass man weiß wo die Entscheidung fiel. Das könnte man ggf auch aufteilen, damit die Tabellen sauberer sind.

Ich werde mal mein Glück versuchen! Wenn ich scheiter, weiß ich ja wenigstens wo ich nachfragen muss!