More > Media Center 14 (Development Ended)
Next -- Relational Database?
leezer3:
Couple of thoughts-
A user submitted YADB isn't really feasible on a relational scale, simply because of the scope for variation. It could possibly be an option to partner with a data source provider if you wanted to implement a DB lookup for relational actor/ artist biographies etc though.
Parent/ child fields aren't bad, but they're nowhere near good enough. Here's an example for you-
I have a lot (C. 2,000) of audiobooks. The basic fields I've used at present are these (Plenty of others, but these are irrelevant at present):
* Author
* Narrator
* Studio (For the audiobook, may also contain publisher)
* Publisher (For the print edition)
A good example for this is Stephen Fry- He is present in both the author and narrator fields. Adding a biography child field would have to be done in both the author and narrator fields, and any updates would have to be manually synced across. This issue also holds for publishers etc.
On the other hand within a relational DB, all that needs to be done (I'm well aware I'm over simplifying the technicalities here) is to establish a link between the base biography field for Stephen Fry, and anywhere that he is used :)
Another issue that would be addressed by a relational DB, would be the ability to add a rating for anything. At present, there's no easy way to apply an overall rating to an artist etc, other than either adding an identical field to all of their files, or a smartlist average. Neither of these is anywhere near perfect, and requires manual updating at best.
Cheers
-Leezer-
hit_ny:
--- Quote from: leezer3 on June 01, 2009, 07:31:21 am ---A good example for this is Stephen Fry- He is present in both the author and narrator fields. Adding a biography child field would have to be done in both the author and narrator fields, and any updates would have to be manually synced across. This issue also holds for publishers etc.
--- End quote ---
By manually are you saying one has to do more than just assign Fry to another file ?
--- Quote from: leezer3 on June 01, 2009, 07:31:21 am ---On the other hand within a relational DB, all that needs to be done (I'm well aware I'm over simplifying the technicalities here) is to establish a link between the base biography field for Stephen Fry, and anywhere that he is used :)
--- End quote ---
You are correct that the Bio field would need to be added twice but its a one off unless the versatile Fry appears in a third role :)
Chances are under the hood this is exactly what happens. Library backups are half the size in 13 compared to v12 so big time pooling happening.
Course the challenge then becomes how do you do the GUI ?
--- Quote from: leezer3 on June 01, 2009, 07:31:21 am ---Another issue that would be addressed by a relational DB, would be the ability to add a rating for anything. At present, there's no easy way to apply an overall rating to an artist etc, other than either adding an identical field to all of their files, or a smartlist average. Neither of these is anywhere near perfect, and requires manual updating at best.
--- End quote ---
Yep
--- Quote from: dcwebman on June 01, 2009, 07:16:47 am ---Unless I missed someone saying it, the item a relationship database could do that people have been asking for years is the ability to assign the exact same song to multiple albums. The answer was always that hard drive space is cheap but why waste the space if all you have to do is point one song to multiple albums? That gives more room to add other songs.
--- End quote ---
I'm not sure how it could be done because there is no suggestion to have a one to many relationship with files. The 1:1 connection will still be retained between the actual files and the list view.
leezer3:
--- Quote from: hit_ny on June 01, 2009, 08:24:19 am ---By manually are you saying one has to do more than just assign Fry to another file ?
--- End quote ---
I'm referring to the major issue with parent/ child fields here which a relational structure would avoid-
Basically, there would be two distinct copies of the data, one the child of the Author field, and one the child of the Narrator field :)
Updating one in a parent/ child structure would not update both.
--- Quote from: hit_ny on June 01, 2009, 08:24:19 am ---You are correct that the Bio field would need to be added twice but its a one off unless the versatile Fry appears in a third role Smiley
Chances are under the hood this is exactly what happens. Library backups are half the size in 13 compared to v12 so big time pooling happening.
Course the challenge then becomes how do you do the GUI ?
--- End quote ---
Stephen Fry was just an example really :)
If things go down this road, I'll need to link his biography to the Actor field, and probably a couple of others as well. An extreme example I admit, but these are the best way to break things ;D
The GUI is perfectly simple when you think about it though. The first thing that needs to be done is to lose much of the current concept of a database field & its contents (Not literally, but I can't think of a better way to put this)-
1. There need to be three distinct types of fields (Again, field isn't really the correct term here)-
* 'Unique per file' fields. These would consist of data such as title, track number etc. (Brown)
* 'Containers'. These fields are simply a container for global fields. (Yellow)
* 'Global' fields. These would be fields which are common between more than one file. They should be able to have child fields added, which can be expanded by default or on a per file basis (White)
It would be necessary for a global field to be a member of any number of containers, all these really are is lists :)
In this example Stephen Fry is a member of both the Authors and Narrators containers, but only his role as a narrator is relevant, hence it is only here that he is displayed.
2. A small button needs to be added to the tag window allowing us to select which Containers our example file possesses (These could be there by default if you prefer). When we've established that it possesses the Narrator and Author containers, these should be editable as any list based field is at present- Select which global field(s) to display from within them.
3. Our file now posesses the Narrator and Author containers, and we've selected the appropriate global fields from within them. The child data for these global fields now populates the file information, so that the presented tags for our file would now look something like this:
Name: Harry Potter
Track: Track #1
Author: JK Rowling
Narrator: Stephen Fry
Narrator Biography: ...........
Obviously, if we don't want his biography displayed in this particular instance, all it needs is a simple right-click option to hide this child field :)
(I apolgise for the rambling nature of this, it's harder to explain on paper than it is to build, honest)
-Leezer-
hit_ny:
No its good what you've said. I think it adds more flexibilty without any sacrifices.
--- Quote from: gappie ---i use a lot of nested fields, i think they are still problematic.
--- End quote ---
There is one point i can offer in support of parent-child here :)
Parent child as i understand it and if darichman agrees, only allows one generation of child. Whereas there is no limit with how many generations one can use with nested fields.
Now whether limiting child to just one generation is a good idea or not from a user perspective, is yet to be decided. But at the implementation level it would keep things quick without too much complexity.
GHammer:
Hmmm.
I see lots of development with little payback.
One thing that comes up over and over is how you could (note the could) assign coverart/images to the same artist. Ok, I'll bite. How many of the same images do you have? Not real practicle for movies I'd think. For a band, maybe. For books, ok, got me there.
A bio would be more useful as a repetitive field.
What fields do you see as most important?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version