More > Media Center 14 (Development Ended)
Next -- Relational Database?
gappie:
--- Quote from: hit_ny on May 30, 2009, 02:13:46 am ---THE person to consult on this is darichman, he has tenaciously posted on this topic at least for the last 3 years.
The YARB thread i think is definitive in terms of his requirements defintion.
YARB -- Relational Database Annual Convention
And the term relational is a misnomer, there is nothing relational in the suggestion wrt to the user. All it suggests is parent-child fields.
--- End quote ---
i dont think its a misnomer, the parent child fields is an other option that has potential. i guess at this moment there is already a few fields that works that way. calculated fields, but still. one is 'album gain'. change the replay gain for one song and see how the album gain is changed for all the songs of that album. the 'album gain' is the child, and the album is the parent (not really, and that makes it more complex, its a combination of album and album artist (auto)).
GHammer: one example a relational database could do, or the parent child field: a lot of times people asked for an album rating field. based on the average of the song rating, or someting a user can set him self. in the case of the relational database the album rating has to be set one time and it shows up for all songs. the parent child variant is in the end the same because the field are set by mc in every song when it changes for one song. (the same problem with parent child field as for replaygain is around the corner, i would not want all my albums called 'live ' have the same rating, in principle this problem should not be there in a relational database.)
the possebilities are big, as shown in the yarb thread, but the complexity introduced should not be ignored and will have its price, and i am worried about that a bit..
:)
gab
hit_ny:
--- Quote from: gappie on May 30, 2009, 03:32:31 am ---i dont think its a misnomer,
--- End quote ---
I meant in the sense that MC is wrt to the user nothing more than a fancy shopping list.
In a relational dB the user can specify links or relations between entities. In MC the only entity is the file. There is no way to specify a link between files automatically. You can perform operations manually via the GUI, ie setting say the Album field or other for a bunch of files.
You cannot use a key from one file to get information about another etc. I think this is a key requirement to use the term relational. Relational implies links or relations between entities.
Now it could well turn out that under-the-hood things are linked up and indirectly DO work in this manner but this functionality cannot be customised specifically by the user. The user is unable to specify what links to what, expressions work only on per file level.
The only user link is that of the GUI with the file.
--- Quote from: gappie on May 30, 2009, 03:32:31 am ---change the replay gain for one song and see how the album gain is changed for all the songs of that album.
--- End quote ---
This is only an exception rather than the general case.
--- Quote from: gappie on May 30, 2009, 03:32:31 am ---a lot of times people asked for an album rating field. based on the average of the song rating, or someting a user can set him self. in the case of the relational database the album rating has to be set one time and it shows up for all songs.
--- End quote ---
I would love to have this kind of functionality, but it would need a grouping ability i think to work. In the sense you would define a group, in this case the [Album] field and then perform operations on all files in that group for many [Albums].
I'm not sure how parent-child could be used in this case.
--- Quote from: gappie on May 30, 2009, 03:32:31 am ---the possebilities are big, as shown in the yarb thread, but the complexity introduced should not be ignored and will have its price, and i am worried about that a bit..
--- End quote ---
This would depend on how open-ended the implementation is. But as darichman has spec'd it out it does not seem to be more problematic that nested fields are currently. Three years ago i would have agreed with you as the library was then not as optimised to the point it is now. My collection has grown during this time but the machine i use is still the same and MC has defnitely become faster in response :)
I pointed out a potential problem with YADB tho i'm not sure how much of a showstopper that will be. People currently use different naming conventions for the same file and it can handle this already.
gappie:
--- Quote from: hit_ny on May 30, 2009, 04:01:35 am ---I meant in the sense that MC is wrt to the user nothing more than a fancy shopping list.
--- End quote ---
i agree, also with the rest of your comment to that item. :)
--- Quote from: hit_ny on May 30, 2009, 04:01:35 am ---This is only an exception rather than the general case.
--- End quote ---
i also agree, just wanted to point out that there was already something like that.
--- Quote from: hit_ny on May 30, 2009, 04:01:35 am ---I would love to have this kind of functionality, but it would need a grouping ability i think to work. In the sense you would define a group, in this case the [Album] field and then perform operations on all files in that group for many [Albums].
I'm not sure how parent-child could be used in this case.
--- End quote ---
i think this is what the patent child is all about. when it is just a wizzard you have to run manually its great, but does not do any right to what people want when asking for an relational database. when i get the artist bios filled in i would expect that when i change a typo in it, it will change for all the fields under the same parent.
--- Quote from: hit_ny on May 30, 2009, 04:01:35 am ---This would depend on how open-ended the implementation is. But as darichman has spec'd it out it does not seem to be more problematic that nested fields are currently. Three years ago i would have agreed with you as the library was then not as optimised to the point it is now. My collection has grown during this time but the machine i use is still the same and MC has defnitely become faster in response :)
I pointed out a potential problem with YADB tho i'm not sure how much of a showstopper that will be. People currently use different naming conventions for the same file and it can handle this already.
--- End quote ---
i use a lot of nested fields, i think they are still problematic. ;)
yes, the database now is working great. and to be sure to get this over, im not opposing the idea, just worried about some black clouds at the horizon.
:)
gab
edit.. with all this fancy quoting i deleted part of my answer :'(.. retyped a shorter version. :P
Marty3d:
Here's a quick list of why using a relational database could be of use for the end user:
* Fields that are unique for an artist, ie Origin, Age, Genre, Pictures associated to an artist etc. would be set only once. When you buy a new album by that artist and import it into MC, all those fields are automatically populated. This means less work.
* Album art is connected to an album, not all files within that album
* Play statistics. Right now, you can only see when a song is LAST played (two fields are filled out, Play count and Last played). That means you cannot see stuff like: 1. "Did I play this song during the last Christmas party?" 2. Yearly/Monthly/Weekly top lists (Top 100 songs 2006 for example)
gappie:
--- Quote from: Marty3d on May 30, 2009, 05:49:18 am ---Here's a quick list of why using a relational database could be of use for the end user:
* Fields that are unique for an artist, ie Origin, Age, Genre, Pictures associated to an artist etc. would be set only once. When you buy a new album by that artist and import it into MC, all those fields are automatically populated. This means less work.
* Album art is connected to an album, not all files within that album
* Play statistics. Right now, you can only see when a song is LAST played (two fields are filled out, Play count and Last played). That means you cannot see stuff like: 1. "Did I play this song during the last Christmas party?" 2. Yearly/Monthly/Weekly top lists (Top 100 songs 2006 for example)
--- End quote ---
now .. i would love something like your 3rd item. and that is something that really calls for a relational database.
:)
gab
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version