Statische Daten in Software hinterlegen

M

MS-Tech

Erfahrenes Mitglied
Hallo,

ich muß in einer Software ca. 6000 einzelne Daten hinterlegen. Die Daten sollten im Produktivbetrieb später relativ einfach zu ändern sein, z.B. Hinterlegung per XML usw.

Diese Daten müssen dann abrufbar sein, wenn ich z.B. ein Objekt A anlege oder im Objekt A einen bestimmten Wert ändere/anlege. Im Objekt A gibts dann eine Tabelle, die dann mit diesen Daten gefüllt werden soll.

Wie kann man sowas am besten realisieren? Gleich anlegen in einer Datenbank? Anlegen per XML u nd dann die XML parsen, falls ich die Daten brauche?

Hat jemand eine Idee?

Viele Grüße

Sascha
 
Die Entscheidung ob du XML, prpoerty Dateien oder eine DB verwenden solltest hängen von verschiedenen Faktoren ab.

1. Soll die Anwendung verteilt laufen, bzw. dies in Zukunft irgentwann unterstützen?
Dann kommst du um eine DB kaum rum.

2. Sind die Daten zu logischen Objekten organisiert oder organisierbar, z.B. 1000 Mitarbeiter, mit jeweils Namen, Vornamen ...?
Solche Muster legen die Verwendung von DBs beziehungsweise XML nahe.

3. Sind die Daten alle vom Typ String oder leicht aus Strings zu parsen (z.B. Integer) haben aber miteinander wenig bis garnichts zu tun.
Hier wäre eine (oder mehrere) Property Datei sinnvoll, da Propertys einfach über Key Value abfragbar sind.

Die drei Lösungen bieten unterschiedliche Vor und Nachteile.
Bei einer DB brauchst du einen Datenbankserver am laufen. D.h. du musst ihn entweder vorher per Hand starten, das von deinem Programm machen lassen oder den Server permanent laufen zu lassen.
Bei großen Textdateien braucht das Parsen seine Zeit. Das heißt, grade wenn du oft einzelne Daten suchst verschwendest du hier leicht ne menge Rechenzeit

MfG

Andreas
 
hi,

danke erstmal für deine Antwort.

Ja die Anwendung sollte später auch verteilt laufen. Deshalb haben wir auch einen Datenbankserver. Die verteilte Architektur steht und läuft bereits.

Ja die Daten sind logisch aufbereitet. Im Endeffekt habe ich hier eine Exceltabelle mit zig Zeilen und Spalten. Der Aufbau ist also immer der gleiche.

Wie die Daten irgendwann vorliegen ist relativ bzw. mir relativ egal. Ich kann auch nur mit Strings arbeiten. Diese Daten sind nichts weiter als reine Informationsdaten, die in einer Tabelle angezeigt werden. Es wird weder die Tabelle gespeichert noch sonstwas. Die Tabelle wird ja im Endeffekt nur immer neu generiert, wenn er Änderungen in einem bestimmten Objekt macht.

Der Vorteil der DB-Lösung liegt ja auf der Hand. Der Nachteil hierbei sind sicherlich die Zugriffszeiten, wenn die Lösung mal verteilt läuft.

Der Nachteil einer Property-Datei ist sicherlich die Zeit des Parsens.

Diese Daten können sich immer laufend verändern. Es sollte eben ein diesbezütlich eine gut anpassbare Lösung sein. Es ist sicherlich einfacher ein Update einer Property-Datei rauszuschicken, als die ganze DB upzudaten.

Gruß

Sascha
 
Wenn sich die Daten häufig ändern ist die DB definitiv der Bessere Weg.

Immerhin müsstest du ja wenn sich ein Datum ändert ja dafür sorgen, dass alle Nutzer des Programms die neue Datei bekommen, und außerdem müsstest du ja auch die Datei jedesmal komplett verteilen.

Änderungen im Datenbestand der DB lassen sich viel einfacher ausführen, da die über einfache SQL Befehle laufen (die fest in deine Programme integriert sind).

Außerdem hast du zusätzlich noch die Möglichkeit Nutzerverwaltung zu betreiben, so dass du Beispielsweise unterschiedlichen Nuzern/Programmen unterschiedliche Zugriffsrechte zugestehst.

Somit ist es auch möglich das aus den Clientprogrammen direkt eine Änderung auf der Datenbank gemacht wird (sofern du das erlauben möchtest).

Die Performance von Datenbanken ist, wenn sie im LAN laufen in der Regel ziemlich gut.

Als einen Subjektiven Wert für eine DB Abfrage an einem entfernteren Server:
Ein Kumpel von mir hat einen DB server auf seinem Heimrechner in Hannover (hinter einem Heimrouter) wenn ich aus Hildesheim drauf zugreife, habe ich immernoch trotz vieler Homeuserkomponenten in der Verbindung kaum Verzögerungen (unter 0,5 sek).
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück