Alternative zu "ausgewachsener" Datenbank - Noch sinnvoll?

[Mithrandir]

Jut,

der Threadtitel ist etwas kryptisch. Es geht sich um folgendes:

Ich habe hier einen kleine Wetterapplikation, die sich in die TNA einnistet. Um dem User das Leben einfacher zu machen, habe ich eine Liste mit ~7000 Flughäfen, die METAR-Wetterdaten senden. Zu dieser Liste gehören Infos über den Standort, den Namen, das Land und die Koordinaten. Außerdem habe ich noch eine Liste aller Postleitzahlen Deutschlands (mit Koordinaten und Städten), um dem User das finden der nächst näheren METAR-Station zu vereinfachen.

Eventuell sollen die Wetterdaten zwecks Archivierung auch gespeichert werden.

Nun habe ich mich für eine Datenbank entschieden, Firebird embedded. Zum Zugriff nutze ich ZEOS. Allerdings wird dadurch der eigentliche Download und das Programm riesig. Mal eine Auflistung

• Exe: 1,8 MB
• Alle FB-Dlls: 5 MB
• SQL-Dump zum erstellen der Datenbank am jew. Speicherort: 2,2 MB

Das macht knapp 10 MB für ein Programm, dass nur das aktuelle Wetter anzeigen soll. Ein bisschen viel, wie ich finde. Zumal die Anwendung im RAM knapp 7 MB belegt. Klar, heutzutage ist Speicherplatz billig, aber dennoch: Für mein Verständnis ist das etwas viel.

Mir fallen zur Lösung des "Problems" mehrere Dinge ein:

• Verzicht auf Firebird & SQL und Daten innerhalb der EXE speichern (Wie?)
• Umstieg auf kleinere SQL-Datenbank (kostenfrei, welche?)
• Umstieg auf XML-Datenbank (uff, Performance?)

Gibts einen vernünftigen Kompromiss, den man eingehen könnte, oder soll ich lieber den Status Quo beibehalten?

Gruß,
Daniel

[Daniel]

Die 7.000 Stationen werden sich ja nicht so häufig ändern. Im Wesentlichen wird's doch eine Liste sein, die Du erstellst und dann auslieferst. Da würde ich, wenn es klein und schnell sein soll, auf typisierte Dateien zurückgreifen. Das ist ratz-fatz gelesen und bei Bedarf sogar wieder geschrieben.

Bleibt die Frage, wie viele Wetterdaten Deine Anwender archivieren sollen und wie oft und wie schnell sie auf das Archiv zugreifen sollen. Ich würde es mal mit XML versuchen, wenn davon auszugehen ist, dass im normalen Anwendungsfall die Datenmenge überschaubar bleibt.

[mquadrat]

Die 2,2 MB für den Dump wirst du nicht loswerden. FB Dumps sind ja schon komprimiert und wenn du die gleiche Menge an Daten zur Verfügung stellen willst, dann kannst du an der Stelle nichts loswerden.

Alternative wäre die Daten per WebService jeweils aus dem Web zu holen. Dann würden nur noch die 1,8 MB für deine Anwendung bleiben. Der Datenbestand sowie das DBMS würden dann ja auf dem Webserver liegen.

Wenn du kein DBMS nutzen möchtest, kannst du auch die Save/Load Funktionen des Datasets nutzen. Die produzieren bzw. konsumieren XML Files, wenn ich nicht irre.

[Mithrandir]

@Daniel:

ja, die Stationen ändern sich gar nicht. Typisierte Dateien klingt nach einer alternative.

Was das Archivieren angeht... Nun ja, wenns wirklich implmentiert wird, dann gibt es 4 Speicherpunkte am Tag. ;)

@mquadrat:

Zitat:

FB Dumps sind ja schon komprimiert

Nö, das ist eine Plaintext-Datei, extrahiert von IBExpert... :stupid:

Zitat:

Alternative wäre die Daten per WebService jeweils aus dem Web zu holen.

Die Idee hatte ich auch. Aber irgendwie sträube ich mich noch, dafür eine Schnittstelle bereitzustellen.

Zitat:

Wenn du kein DBMS nutzen möchtest, kannst du auch die Save/Load Funktionen des Datasets nutzen. Die produzieren bzw. konsumieren XML Files, wenn ich nicht irre.

Hm, ja, irgendwas war da mal... :gruebel:

[jaenicke]

Du könntest auch SQLite oder ähnliches benutzen, die DLL ist relativ klein (300 KiB oder so).

[Mithrandir]

Aber dennoch brauch ich ja noch ZEOS zum Zugriff, oder? Pumpt immerhin 1 MB in meine Exe...

[mquadrat]

Zitat:

Zitat von Daniel G

[...]
Nö, das ist eine Plaintext-Datei, extrahiert von IBExpert... :stupid:
[...]
Die Idee hatte ich auch. Aber irgendwie sträube ich mich noch, dafür eine Schnittstelle bereitzustellen.

Sorry, meinte Backup statt Dump :oops:

Also die konsumierende Schnittstelle ist einfach, da gibt es ja nen Wizard zu.

[jaenicke]

Bei SQLite brauchst du gar nix weiter. Nur die Datendatei und natürlich die Schnittstellenunit. ;-)

[Mithrandir]

Dit wiederum klingt nach einer vernünftigen Alternative, um die vorzüge einer SQL-Datenbank nicht aufgeben zu müssen (gerade in Bezug auf Umkreissuche, etc.)... Ich guck mir SQLite mal genauer an, danke. ;)

[himitsu]

und was die 7000 Flughäfen + Zusatzdaten angeht ... selbst als XML sollte das, mit 'ner halbwegs schnellen Lib, innerhalb von vielleicht nur maximal 'ner halben Sekunde geladen sein. :angel: