@Bug: Eine Aufwandsanalyse ist
imho wichtig. Sieht man am Anfang schon ein Problem, welches die Realisierung beeinträchtigen/verhindern könnte, wäre es fahrlässig dieses einfach auszublenden
Natürlich ist es wichtig, das man sich im Klarem darüber ist, dass der Index eventuell sehr groß wird.
Allerdings ist es sinnlos, jetzt darüber zu diskutieren ob der Index bei 5000 Liedern bei 20kB, 2MB oder 200 MB liegt.
Man könnte sich zum Beispiel überlegen, dass, wenn man am Anfang alle Lieder mit gleichem BPM verknüpft, man bereits am Anfang sehr viele Kanten hat.
Damit könnte es tatsächlich klug sein, gleich eine Matrix zu nehmen. Allerdings muss man dann in Kauf nehmen, dass bei Hinzufügen eines Liedes der Speicherbedarf quadratisch mit der Anzahl der Knoten steigt.
Wenn die Kanten nach und nach hinzugefügt werden, wäre es dann eventuell besser, eine andere Darstellung zu wählen und das Organisieren der Daten zB. SQLite zu überlassen.
Letztlich gewinnt man bei dieser Überlegung nicht viel, wenn sie am Anfang steht. Wenn die Kantenwerte genau so groß sind wie die Knotenbezeichner (und das wäre dann vermutlich wenig), dann kostet die Speicherung aller möglichen Kanten in einem Graphen als Matrix nur ca. 1/3.
Das ist doch kein so großartiger Faktor, zumal wir noch nicht wissen, wie die Anzahl der Kanten von der Anzahl der Knoten abhängt.
Allein um jedes Lied nach jedem anderem zu anzuspielen (und nach 3 Sekunden weiterzuskippen, ohne Pause) bräuchte man ca. 2,4 Jahre.
Das heißt wenn man die Anzahl der anfänglichen Kanten nicht so hoch setzt, wird sehr lange dauern, bis alle Kanten gesetzt sind.