Daten aus DB holen oder im Speicher halten?

[flowh]

Hallo miteinander!

Ich bin dabei ein kleines MP3-Verwaltungstool zu schreiben, da die existierenden Programme in der Richtung alle nicht das machen, was ich will.

Dabei bin ich auf folgendes Problem gestoßen:
In einer GUI sollen alles Lieder angezeigt werden, mit der Möglichkeit diese zu filtern, zu durchsuchen, zu bearbeiten (die ID3-Tags), zu sortieren, etc... Jedes Lied ist ein Objekt meiner Klasse Song (Eigenschaften: Titel, Interpret, Album etc),
als DBMS verwende ich MySQL

Wie gehe ich denn jetzt genau vor?
[1] Macht es Sinn einmal beim Programmstart die Songs aus der Datenbank zu holen, während des Programmablaufs im Speicher zu halten (über 20.000 Objekte), alle Aktionen wie Sortieren etc mit einer Collection der Songs zu realisiern und beim Programmende alle Änderungen in die Datenbank zu übernehmen?
[2] Oder ist es besser, alle Aktionen direkt auf der Datenbank auszuführen und dann bloß die Anzeige zu aktualisieren?
(Bei [1] befürchte ich enormen Speicherverbrauch, bei [2] denke ich dass die Anfragen an die Datenbank nicht in "Echtzeit" durchgeführt werden können, um eine möglichst flüssige GUI zu erhalten.)

Für eure Antworten schon im Voraus vielen Dank!

Ciao,

Flo

 

[sparrow]

Och, ich kenne ein Programm was all das kann.
Nennt sich Amarok, Wiki kennt es genauer.

Ansonsten würde ich Methode 2 anwenden und als Datenbank: HSQLDB.

 

[flowh]

Och, ich kenne ein Programm was all das kann.
Nennt sich Amarok, Wiki kennt es genauer.

Ansonsten würde ich Methode 2 anwenden und als Datenbank: HSQLDB.

Vielen Dank für den Hinweis auf HSQLDB!!

Ja natürlich kann Amarok das, aber erstens müsste man das unter Ubuntu erstmal zum laufen bringen, zweitens machts dann doch nicht _genau_ das, was ich will und drittens brauch ich doch einen guten Grund, etwas zu programmieren.

 

[KSG9|sebastian]

warum HSQLDB? Wenn dann eher Derby?! Aber was spricht den gegen MySQL?

 

[hupfdule]

warum HSQLDB?

Warum eher Derby als HSQLDB?

 

[sparrow]

warum HSQLDB? Wenn dann eher Derby?! Aber was spricht den gegen MySQL?

MySQL fällt an dieser Stelle deutlich raus.
Wieso soll man einem potentiellen Anwender denn dazu zwingen eine "große" Datenbank wie mySQL aufzusetzen? Das ist definitiv ein nicht zumutbarer Aufwand.

Derby und HSQLDB nehmen sich für das hier angesprochene Problem nichts, wobei ich HSQLDB wegen seiner Bekanntheit bevorzugen würde, außerdem dürfte es in diesem Fall deutlisch schneller sein.

 

[Guest]

MySQL fällt an dieser Stelle deutlich raus.
Wieso soll man einem potentiellen Anwender denn dazu zwingen eine "große" Datenbank wie mySQL aufzusetzen? Das ist definitiv ein nicht zumutbarer Aufwand.

Das Programm ist ja (zumindestens vorerst) mal nur für mich gedacht... deswegen hab ich mir da keine großen Gedanken gemacht. Ob es jemals veröffentlichungs-würdig werden wird, steht grad noch in den Sternen, aber wenn dann werde ich es euch davor auf jeden Fall mal vorstellen.

 

[flowh]

Nochmal zu HSQLDB: Ich hab gerade H2 gefunden, die ist angeblich noch schneller... irgendwelche Einwände dagegen?

 

[SamHotte]

Bei 20.000 Datensätzen wird man sich etwas schwer tun, den einen oder anderen Geschwindigkeitsvorteil überhaupt zu bemerken

 

[flowh]

Bei 20.000 Datensätzen wird man sich etwas schwer tun, den einen oder anderen Geschwindigkeitsvorteil überhaupt zu bemerken

Wieso denn? Weil 20.000 für eine Datenbank verhältnismäßig wenige Datensätze sind?

 

[SamHotte]

Jepp. Normale Datenbanken fangen so bei 'ner halben Mio. an, richtig Spaß zu bekommen

 

[flowh]

Jepp. Normale Datenbanken fangen so bei 'ner halben Mio. an, richtig Spaß zu bekommen

Ok... dann brauch ich mir ja da keine großen Gedanken zu machen.

Danke für die Info!