Speicherung von Daten: Datenbank(sql) oder xml?

[siR]

Hallo,

ich habe eine tabelle die einen Tag in der woche darstellt. Nun kann ich mit einem links/rechts oder vor/zurück-Button zum nächsten/vorherigen Tag im Planer springen bzw. die Daten auf die der "zeiger" vorherig/danach zeigt werden geladen. Nun frage ich mich wie ich diese Daten am besten speichere?

Da dieser Planer ja eine Tabelle ist wäre eine Datenbankdatei nicht schlecht oder? z.B.: H2 , da ich aber auch gerade JAXB 2.0 lerne frage ich mich ebenso ob eine Speicherung der Daten in eine .XML Datei in Frage kommen könnte.

Wäre das nicht ein bißchen viel für ne .xml Datei? Vor allem Daten aus einer TAbelle passen halt so schön... zu einer Datenkbankspeicherung ???:L

Was meint Ihr?

 

[André Uhres]

Naja, wenn man mir sagen würde, du kannst sql oder xml verwenden, dann würde ich sql nehmen,
obschon für kleinere Datenmengen der XMLEncoder sehr praktisch ist (Beispiele mit XMLEncoder: TableSave.jar, RatingDemo.jar).

 

[kama]

Hi,

wie wäre es mit XStream...

fand und finde ich für kleinere Datenmengen immer noch besser als SQL (selbst als H2)...

Hier wäre nur die Frage wie "kleinere Datenmenge" zu definieren ist....;-)


MfG
Karl Heinz Marbaise

 

[André Uhres]

..Hier wäre nur die Frage wie "kleinere Datenmenge" zu definieren ist..

Was bequem in den Arbeitspeicher passt :wink:
XStream kannte ich noch nicht.

 

[quippy]

Naja, wenn man mir sagen würde, du kannst sql oder xml verwenden, dann würde ich sql nehmen,
obschon für kleinere Datenmengen der XMLEncoder sehr praktisch ist (Beispiele mit XMLEncoder: TableSave.jar, RatingDemo.jar).

Der XMLEncoder ist meines Wissens nach nur eine Variante, Objekte auf der Platte zu serialisieren. Dabei müssen
a) der Standardkonstruktor
b) Setter- und Getter-Methoden nach Konvention (also getName(); setName(String newName); )
vorhanden sein.

Als Datenbankersatz meiner Meinung nach also nicht wirklich geeignet.

Zudem kommt es nun darauf an, wie die Daten selektiert und gespeichert werden sollen. Man könnte zwar jede Tabellenzeile als Objekt auffassen und dann ablegen, das halte ich aber nicht für so geschickt.

Das Anwendungsbeispiel verlangt nach meiner Auffassung eher nach einer Datenbank - immerhin solles ein Datumsplaner werden. Alternativ kann man da eher eine Index-Sequentielle Datei verwenden.

 

[André Uhres]

XMLEncoder ist für Beans. Niemand hat je von einer Bean als "Datenbankersatz" gesprochen.
Man kann dagegen ein TableModel sehr wohl als Bean betrachten.
Ob das für den vorgestellten Terminplaner reicht, sollte für den Entwickler eh sofort klar sein.
Jedenfalls sollte das Design unabhängig von der schliesslich gewählten Art der Datensicherung sein.

 

[siR]

Also was ich so raushöre ist demnach eine Datenbank eher zu empfehlen, die letztendlich sich aus vielen Tabellen zusammensetzt. Um das ganze zu unterstreichen - wollte ich nicht erwähnen, da es zuviel Einfluss genommen hätte evtl.- ein kommerzielles Produkt das ich kenne ist in Visual Basic programmiert und benutzt dafür eine .mdb sprich Microsoft Access Datenbank mit ca. 15 Tabellen. Außer dem "Terminplaner" kommen noch andere Sachen dazu... also würdet ihr mir H2 empfehlen?

 

[André Uhres]

Ich hab sehr grosse Datenbanken in MySQL und bin ganz zufrieden damit. Mit SyBase hab ich dagegen eher schlechte Erfahrung gemacht, von der Performance her. Für dein relativ bescheidenes Projekt spielt die Wahl der Db aber wohl eine ziemlich untergeordnete Rolle.

 

[siR]

Für dein relativ bescheidenes Projekt spielt die Wahl der Db aber wohl eine ziemlich untergeordnete Rolle.

80 kb .PDF datei mit den groben Anforderungen an das Programm: http://www.sendspace.com/file/q5shbs

Bitte kurz anschauen wegen endgültiger Empfehlung ;-)

 

[xote]

[...]also würdet ihr mir H2 empfehlen?

Die Wahl wie du es abspeicherst hängt aber doch von der Menge ab, die am Ende drinsteht. Wenn der Terminplaner mal ein Jahr läuft, und jemand möchte wissen was letztes Jahr war, hmm, schwierige Frage...

Also ich lese und programmiere mich gerade in JDBC (mit H2) rein. Ich finds nicht schlecht. Mir kommt auch die Lizenz entgegen. Es ist nicht besonders schwer, und mit SQL Querys ist es IMHO sehr leicht zu arbeiten.