[mythtv] MythMusic database schema suggestion

thor mythtv at lamedomainname.com
Tue Jun 24 04:30:48 EDT 2003


On Monday 23 June 2003 07:56 pm, Brian Lalor wrote:

> In looking at the structure of the MythMusic database schema, I decided a
> lot of that data could be minimized and normalized to make for more
> efficient queries and to allow the database to do more of the work for
> searching for result sets while at the same time not having to work quite
> as hard.  

	The schema is not ideal. That's a given. But it is loaded into memory and 
only written out (on a "per-changed" basis during a mythmusic exit). In the 
near future, it will only be written out on a backend exit.

> I took a couple of minutes and whacked out what I think is a
> reasonable facsimile of a better database layout as it pertains to
> MythMusic.  The things that bother me about the current structure (as of
> 0.9.1) is the repetition of data for artist and album information for each
> track

	There is currently a clean mapping between a "track" (file on disk), and 
metadata information. Any attempt to squeak efficiencies out of this is 
probably doomed to failure. A new file means what? Deleting a file means 
what? Re-tagging a file with another application (while myth is *not* 
running) means what?


> and the way that playlists are stored. 

	playlists are clearly sub-optimal. Someone should be able to improve on 
comma-delimited strings. I await a precise description of how to do this 
better. This would be very welcome, as I am far from a DB/SQL expert ;-)

>
> I'm much stronger at SQL than I am at C++; 
>

	This is, unfortunately, often the difference between theory and practice. If 
the target application (i.e. MythMusic/C++) needs a read for every track, 
then extra tables for artists and albums actually increase the startup 
burden. 

- thor
	



More information about the mythtv-dev mailing list