wir haben Build 4385 veröffentlicht (letzter Snapshot), welcher für alle bestehenden Datenbanken eine Verbesserung darstellt:
Snapshot - Build 4385
(...)
[*] DB: Added SQL index to speed up loading time for larger database with
a long playback history
[+] DB: Added "Check Indices" maintenance function
Speziell der Hinweis auf “a long playback history” = Rotationsserver oder zentralisierte Musikdatenbanken zeigt, dass die Ladezeit beschleunigt werden kann.
Aber auch für lokale Datenbanken ist das hilfreich.
Spätestens mit Version 6.3.7 (in Planung) wird das produktiv, aber wir empfehlen bereits jetzt ein Download und die Installation des Snapshots.
Danach könnt ihr in der Konfiguration oder Systemsteuerung die Wartung durchführen:
Aber die Einträge werden doch nicht auf den päpstlichen Index (dessen Plural annähernd unsinnig ist), sondern sie bekommen ein individuelles Attribut, eben jeweils einen Index. Beziehungsweise eben Indizes.
Sorry, Hochschulmathematik hinterläßt Spuren. (Jedenfalls bei mir.)
Ja. Deshalb schrieb ich: Weiterlesen.
In der Mathematik heißt es eben auch Indizes. Wie in der Statistik. Was ja wohl eher auf Mairlist zutrifft als der päpstliche Index. Hoffe ich
Ganz unten bei Grammatik heißt es dann auch:
“der Index; Genitiv: des Index[es], Plural: die Indexe und Indizes, auch: Indices […ditseːs]”
Im Englischen scheint mir “indices” gebräuchlicher zu sein, im Deutschen (auf SQL bezogen) “Indexe”, weswegen ich in diese Form in der Übersetzung gewählt habe.
Würde so ein Index nicht auch die Möglichkeit eröffnen, Search as you type einzuführen?
Das wurde schon ein paar mal diskutiert aber ich finde die Threads gerade nicht wieder, es wurde wohl namentlich so nicht benannt. Unter Search as you type findet sich jedenfalls nur ein alter Beitrag von mir, ich bin mir aber relativ sicher, dass das mehrfach Thema gewesen ist.
Ich habe gerade am Montag noch mit @CoolSpot darüber gesprochen, dass Ihm das Feature sehr fehlt. Daher scheint es mir hier gerade gut rein zu passen.
Es war ein Performance Problem, weshalb das bisher nicht ging wenn ich recht erinnere.
Das sollte ja mit so einem Index, nicht mehr das Problem sein, denke ich.
Nein, das hat nicht direkt etwas miteinander zu tun.
Was hier fehlte, war ein einfacher SQL-Index auf die Tabelle playlistlog, wo ich schnell nach einem bestimmten Element (und der Station und der Uhrzeit) suchen kann.
In Version 6.3.3 haben wir die Spalte “zuletzt gespielt” in der Bibliothek hinzugefügt. Seitdem muss bei jedem Zugriff auf die Bibliothek diese Tabelle auch mit betrachtet werden (per LEFT JOIN), und da fehlte eben ein Index, um dies effizient durchzuführen. Und je länger die Historie in der playlistlog-Tabelle, desto schlimmer war es.
Dies kann, je nach Datenbank, mehrere Minuten dauern.
Wir empfehlen, die Datenbank vorab zu sichern.
