Ehrlich gesagt bin ich in Sachen Datenbanken noch nicht so fit. Grundbegriffe wie Indizes, PK, FK, SP sind bekannt. Aber wie würde ich solche Relationen abbilden bzw.
SQL zu meinem Zweck nutzen? Wie "programmiere" ich mit SQLite?
Also in Sachen
SQL kann ich absolut das Buch "The Definitive Guide to SQLite" von Mike Owens empfehlen. Ich hatte schon vorher genügend mit
MySQL und auch teils mit PostgreSQL zu tun, aber detailliert verstanden habe ich die Zusammenhänge hinter
SQL erst nach der Lektüre dieses Buches. Übrigens ist die Besprechung von
SQL im Buch nicht auf SQLite beschränkt sondern es geht mehr um das Grundlagenwissen. Und mit Grundlagenwissen will ich keinesfalls kleinreden wie detailliert die Beschreibung ist - vielmehr wird dort auch auf die mathematischen Grundlagen hinter dem was heute
SQL ist eingegangen. Es handelt sich in diesem Sinne also nicht um eine bloße Einführung in das Thema.
"Using SQLite" (erschienen bei O'Reilly, und ich habe es auch noch nicht durchgelesen sondern "drübergeblättert") scheint mehr auf die Anwendung von SQLite fokussiert zu sein - gerade wie der Titel es suggeriert
Okay, nun zu dem was ich meinte. Die Frage ist, ob dies mit einer machinenerstellbaren Metrik (BPM, Metatag auslesen) funktionieren könnte. Meines Erachtens nach werden subjektive Daten des Benutzers wie "Stimmung" eher von Relevanz sein, was dann durch ein Zusammenführen auf einem Server zu ungleich besseren Ergebnissen führen würde. Aber: statt eindimensional einen Vertex abzuspeichern (übrigens macht m.M.n. allein die Eindimensionalität ein späteres Ausbalancieren oder andere Modifikationen am Gesamtgraphen schwer bis unmöglich) stellen wir uns einmal vor wie es aussähe, würden wir "Queen" in
Einheiten von "Pink Floyd" abbilden (diese Beziehung wäre automatisch gegenseitig). Ähnlich würde Chopin in Mozarts abgebildet oder Beethoven in Vivaldis. Wenn man einen nicht-NULL-Wert hat, gibt es sozusagen einen Vertex der zwei Titel von "Queen" und "Pink Floyd" verbinden könnte. Eine clevere Datenbank wird entgegen der Aussagen einiger Vorredner eben nicht alle Daten allozieren. Selbst bei Dateisystemen sind "sparse files" seit Jahren Usus. Entsprechend würden nur jene Beziehungen Platz beanspruchen die existieren (plus ein wenig Overhead). Jede Tabelle wäre dabei nur die ID des Liedes und der eigentliche Wert für den Parameter.
Beim Sammeln der Daten könnte man dann die Mastertabelle nach dem Namen aller Tabellen befragen die eine Beziehung zwischen Künstlern abbilden. Ein entsprechendes Schema könnte auch für Melodien und "Stimmung" angewendet werden, wobei man gewisse Parameter (melancholisch vs. lustig usw.) vordefinieren müßte. Zuerst müßte man dann vom aktuellen Lied einige Kennwerte ermitteln (inklusive derer die der Benutzer angibt). Daraufhin kann man dann Lieder ermitteln deren Kennwerte sich gleichen. Zuerst indem man überhaupt Lieder ermittelt die den gleichen oder mindestens x Kennwerte mit dem aktuellen Lied teilt und dann weiter eingrenzend solche innerhalb eines (vermutlich konfigurierbaren) Bereichs.
Zusammenfassend:
die Namen der Tabellen müssen
nicht zwangsläufig in deinem Programm vordefiniert sein. Es gibt Metatabellen in SQLite die es erlauben sowas dynamisch zu ermitteln. Habe ich schon gemacht und funktioniert wunderbar. Und solcherlei Dinge kann man ad infinitum schachteln um die Effizienz von SQLite bei dem Verarbeiten der Daten (mithilfe von
SQL) zu nutzen anstatt Beziehungen die in
SQL leicht und gut darstellbar sind in der Hostsprache nachzumodellieren.