[Java] Musiksammlung verwalten

dann mach ich mal serialisiert weiter, thx

noch eine frage: gibts irgendwelche conventions/standards, wo config-dateien und so hingespeichert werden? hat wer einen link?

Zitat von prayerslayer

hmmm... da ich das ding in erster linie für mich schreiben würde, tät mich natürlich interessieren, wie sich die performance von serialisierter library und datenbank bei einer musiksammlung von ~15-20k tracks verhält.
praktischer wäre es wahrscheinlich, vom gefühl her... :/

kann ich das irgendwie abschätzen? ich möchte nicht alles mit serialisierung fertigcoden um draufzukommen, dass es suckt

naja, da gehts dann halt um komplexitätsabschätzungen. der nachteil bei sequentieller suche ist halt, dass der suchaufwand immer linear O(n) mit der anzahl der musiktracks steigt.

wenn du als datenstruktur beispielsweise kein array oder linked list verwendest, sondern einen binärbaum (in java wird ein sich selbst ordnender red/black-tree verwendet, ähnlich den avl-trees), dann sieht das ganze schon sehr viel besser aus. der aufwand steigt hier nämlich nur noch logarithmisch, also O(log n). wenn du nun einen track unter 20.000 finden willst, musst du nicht mehr alle 20.000 einträge in deiner datenstruktur durchgehen, sondern nur noch 15, um ein gesuchtes element zurückzugeben oder herauszufinden, dass dieser track nicht existiert.
außerdem hast du den vorteil, dass deine sammlung stehts geordnet ausgegeben werden kann.

wenn du als datenstruktur eine hashtable wählst, ist der suchaufwand sogar nicht mehr von der anzahl der tracks, sondern vom füllgrad der tabelle. und solange diese nicht zu ca. 3/4 gefüllt ist, erfolgt das resultat sogar in konstanter zeit, also O(1).

eine datenbank hat den vorteil, dass du auf sehr einfache weise an alle möglichen informationen rankommst, beispielsweise:
- alle tracks eines bestimmten interpreten
- alle tracks mit dem genre metal, die vor 2000 erschienen sind und eine bitrate >= 192 haben
- alle tracks eines interpreten mit einem hohen rating
....
klassische sql-queries halt. der große vorteil dabei ist, dass du dich hierbei nicht um die datenstruktur selbst kümmern musst, da dies alles von der datenbank selbst erledigt wird. durch die interne datenstruktur der datenbank (üblicherweise ein b-baum oder eine variante davon) sind abfragen so schnell, dass du auch mit 100.000 oder mehr tracks keine gröberen probleme haben solltest.

die wahl bleibt natürlich dir überlassen. es hängt halt davon ab, was du hauptsächlich mit der music collection machen willst. du könntest ja das schreiben von datenstrukturen von einem interface abhängig machen lassen, damit du mehrere konkrete klassen schreibst, welche die unterschiedlichen arten, eine struktur zu verwalten, durchgehen. damit hast du den vorteil, dass die klassen austauschbar bleiben.

der vorteil der serialisierung ist halt, dass beim lesen keine neuen strukturen mehr erstellt werden müssen, da der zustand der klasse ja direkt gespeichert wird. das lesen geht also sehr schnell. dafür dauert das schreiben evtl. etwas länger. hab das noch nie versucht für eine große sammlung.

was verwendest du eigentlich derzeit für eine struktur, um einträge zu speichern? ein array, das anschließend serialisiert wird?

ich stell meine verzeichnisstruktur der library in einem jtree dar. mein problem ist, dass der den aktuellen zustand und nicht den in der db gespeicherten repräsentiert, d.h. es können files auftauchen, die noch nicht in der db sind.

es wäre deswegen ganz fein, wenn der tree die in der db gespeicherte verzeichnisstruktur anzeigen würde. allerdings stehen in der db nur die pfade zu den einzelnen files.

mein ansatz wäre jetzt eben gewesen, noch eine directory-table einzubauen, in etwa so:

Code:

TABLE Directory (
DirID INTEGER PRIMARY KEY,
Parent INTEGER);

TABLE SubDir (
Parent INTEGER,
SubDir INTEGER
);

TABLE Files_in_Dir(
Dir INTEGER,
File STRING);

wobei Parent, Dir und SubDir FKs auf DirID von Directory und File ein FK auf den Dateinamen in File.

gute lösung?

Ich sag noch immer, Textfile!