Sofern keiner Einwände geltend macht
bzw. eine bessere Lösung anbietet werde ich das jetzt mit einer Ini lösen.
Das soll dann etwas so aussehen:
Zitat:
[Allgemein]
Dateiformat=1
[Mannschaften]
1=2009073118591180602009073119122234751
2=2009073118591180602009073119122234752
[2009073118591180602009073119122234751]
{ClassName}=TMannschaft
Name=Halle
Spieler1=2009073118591180602009073119122234753
Spieler2=2009073118591180602009073119122234754
[2009073118591180602009073119122234752]
{ClassName}=TMannschaft
Name=Leipzig
Spieler1=2009073118591180602009073119122234755
Spieler2=2009073118591180602009073119122234756
Spieler3=2009073118591180602009073119122234757
Spieler4=2009073118591180602009073119122234758
[2009073118591180602009073119122234753]
{ClassName}=TSpieler
Name=Stahli
Bild=...Base64Daten...
...
Der Export und Import wird dann nicht direkt aus der Datenbank erfolgen sondern über die Komponenten, die das Projekt aus den Datenbankdaten erstellt hat. Die Komponenten kapseln dann Ihrerseits die bereits ausgelesenen Daten.
Die langen Schlüssel sind eindeutige ID´s, ähnlich
GUID´s.
So können Dateien leicht auf Gleichheit geprüft werden und beim Importieren lassen sich Dateiformatänderungen leicht berücksichtigen, ohne dass diese zu Fehlern führen.
Wenn z.B. die Bilddaten künftig nicht mehr benötigt werden, ruft die Imortfunktion diese einfach nicht mehr ab. Dass sie noch in der Ini stehen, ist unproblematisch.
Das halte ich für einen großen Vorteil von Ini´s.
Dadurch, dass der Klassenname jedes Objektes mit in der Ini steht, lassen sich Objekte auch leicht rekonstruieren, wenn dabei unterschiedliche Klassen in einer Liste enthalten sein können.
Im obigen Beispiel ist z.B. eine zu importierende Mannschaft ihrerseits dafür verantwortlich ihre zugehörigen Spieler zu importieren usw.
Beim Import kann dann geprüft werden, ob gleichartige Datensätze schon existieren und dann gefragt werden, ob diese überschrieben werden sollen.
Eine ähnliche Lösung habe ich früher schon einmal umgesetzt.
Stahli