[mythtv] [mythtv-commits] mythtv commit: r10078 by ijr

[Colin Guthrie]

Isaac Richards wrote:
>>I did originally plan on changing it to a table defining the playlist
>>(auto-id + name) and a link table that contained (pl_id, song_id, order
>>{as db order cannot be guarenteed - especially for reordering etc.}).
> 
> 
> I dislike schemas like this.  Leads to more database hits/work during editing, 
> which ends up getting slow.

It all depends on how you structure it. It can actually end up being a 
lot faster for certain things e.g. reordering playlist items etc. 
Clearing all the songs in a playlist is just a single delete statement, 
and even inserting can be very quick if you use MySQL's extended insert 
syntax (this is what caused me to suggest a multi-row insert wrapper 
object in an earlier thread which you may recall). With this wrapper it 
requires no more looping than the current code and typically the same 
number of hits to the database too.

In fact in many cases, the work is reduced - e.g. if you remove a track 
from a playlist, the code only needs to issue a single delete statement 
to the database to update it, it ceases the requirement in the code to 
loop through all the songs to create the concatentated list of ids.

I do know what you mean tho' and in some ways it is easier the way it 
is, but I just can't shake the feeling that storing id's in a relational 
database as comma separated strings is just wrong.... even if it is 
easier/faster in some cases ;)

Inserting a track would require two DB hits but again misses out the 
requirement for a full "for" loop of the songs in code which for large 
playlists is probably quicker.

> Playlists containing other playlists is an absolute requirement.

Cool. I guess the other guys on this thread don't need to ask about this 
any more :)

Col.

-- 

+------------------------+
|     Colin Guthrie      |
+------------------------+
| myth(at)colin.guthr.ie |
| http://colin.guthr.ie/ |
+------------------------+