@gusdesigns wrote:
@zuovo2 wrote:
I’m guessing that this performance issue could also be fixed on the server if Firefly maintained a separate “artists” table in songs.db.
Ron,
Is this statement correct? Is there no such table?
There is indeed no such table. But I don’t think it would help performance. In fact, I think it would hinder it. Here’s why: you’d have to either join those tables in memory when spooling out the song info (which the slug couldn’t do without being reaped by the oom killer), or you’d have to merge it to a temp table (that looks just like the songs table does right now) and then stream that out.
Bottom line is that it would kill the slug. Nope. I don’t think it gets faster with sqlite on the slug.
Performance can certainly be improved, though. But I think the way to do that is to move to a quicker backend, though. I think a gdb backend again will help speed it up.
Interestingly enough, though, thats another argument against normalizing the songs table — it makes it difficult to implement with a backend db that *isn’t* relational. Like gdb.
nope, all in all I think normalizing the tables is a bad idea, both from a performance standpoint and a maintenance standpoint. That’s my take anyway.
— Ron