More > Media Center 14 (Development Ended)
Next -- Relational Database?
gappie:
--- Quote from: hit_ny on June 02, 2009, 10:08:06 am ---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.
--- End quote ---
yes.. ;D i thought the same, on the otherhand, a relational database could make the nested fields more or less redundant... ;)
what i would like to know is: is mc really thinking about the possebilities of a relational db or a child parent one? all options have pros and cons, and it depends so much on the implementation, that i think the discussion about which is to preferr is not so interesting as the one what should be the end result. i mean.. what is the goal. and i think the answer for that is fairly clear when reading this thread and a few previous ones.. which tool to use to get there is the next step.
:)
gab
leezer3:
Important fields which I'd be using in a relational manner (I use these in Artist, Director, Narrator and Author at present, but would like to extend these further):
* Biography.
* Notes. (Different purpose to biography, may contain comments on style etc)
* Portrait.
* Rating- Important for all of these :) I've currently got a kludged smartlist, but the ability to assign a unique rating to anything be exceedingly nice; For example:
List all audiobooks with an author rating of 3 or above, and a narrator rating of 4. This basically gives the opportunity to revist things, and also a good way to instantly sort new stuff into what it's likely to be like. An album rating which isn't a kludge would also be most welcome.
I'm also looking to be able to do things like adding a DVD cover to a TV series, and then having individual thumbnails for each file. The theatre view viewscheme for this would work something like this:
1. Root level- List of genres. Basically as it is now.
2. Second level- List of overarching series within a genre. Again relatively as it is now- Thumbnail displayed would be generated from the series images (DVD covers).
3. Third level- List of induvidual series. Thumbnail for each series is the series image (DVD cover for individual series).
3. Final level- Episode thumbnails.
Equally, the second level could be eliminated (Or alphabetical for that matter), but I prefer to keep remakes etc. within a series structure.
If you want me to be honest, a relational DB is one of those things which you're either going to use or not. I have a combined total of over a thousand authors and narrators which if a relational DB was implemented I'd be doing major work on, simply as all of the data is of use to me one way or another :)
The core programming concepts themselves are also relatively simple (Although I'll freely admit that implementing them into something like MC may require very major work; All I really am is a dabbler at best!), all it really requires to do this is an appropriate way to query the database and provide the data returned in an intelligent way :)
Something like this anyway- An author is stored in the file's unique record. The DB engine then queries the author's container and locates the author named. The data for the author is then presented transparently within the file's tags and is editable. Any changes are written back to the global author.
Most of the work would IMHO go into sorting the GUI and presentation so that things seem relatively transparent, rather than pure backend work.
Cheers
-Leezer-
GHammer:
I think the entire project would depend upon the existing MC database.
If it were easy (relative) to extend/change to a relational database, if all the code that uses the database were reusable, then I'd be in favor.
If those things were not true, then it wouldn't matter because I suspect that a rewrite of MC is not gonna happen.
For my limited needs, the stock tags suffice. For audio. Video and images, well... But those tags would be served fine from the existing database.
darichman:
I was a little reticent to ask for something that would be a) too hard for the user to pick up b) too difficult to implement, which is why we came up with the Parent/Child field concept, which isn't a big jump from where we are now. It's simplistic, but still more functional than the current "file-centric" model.
Put simply, I think MC could benefit greatly from the ability to establish "Containers" (with their own attributes, art etc). Files and other containers could then be assigned to a container and inherit any associated information. Call them containers, parent fields, elements, or whatever... the naming isn't all that important, just the functional outcome for the user.
--- Quote from: leezer3 on June 01, 2009, 07:31:21 am ---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 :)
--- End quote ---
I'm not attached to this idea - it's just the best I could come up with that didn't stray too far from current implementation. Would it work if child fields could belong to more than one parent field concurrently? The program would then need to know that Stephen Fry the author and Stephen Fry the narrator is the same person.
What if like fields could be grouped together in a container of sorts? Like fields would then share similar child fields.
Container: Work.... [Album] [Film] [Show] [Classical Work] [Art Collection] [Book]
Container: Credits... [Artist] [Composer] [Soloist] [Band/Orchestra] [Conductor] [Lyricist] [Actors] [Director] [Producers] [Screenwriter] [Studios] [Author] [Publisher]... all are really "Credits" entities... the actual entries ("Stephen Fry" for eg) could be stored in any of the Credit fields. The Stephen Fry entry could then be edited (bio etc) from any of the fields, as he is effectively the same person in the database (just in different "roles")
I know I just jump from one idea to the next sometimes... just brainstorming :-\
hit_ny:
Haha, going from parent-child or embedding to multiple inheritance :)
Container as a concept does not exist in MC, this appears to be more flexible as leezer pointed out but unless Matt says something we will not know how feasible this idea is. As its implies links 'across' files whereas currently eveything is a highly tuned shopping list or line items with no knowledge of other line items. Adding links to other items will slow things down depending on how the user specifies those links. This is why MC currently can handle as many items as it does and can scale.
So to reuse code, it means keeping the same line item approach and not introducing links between items. Nested fields & list fields are possible as its just operating on the same line item. One uses a ';' to delimit, the other a '\' but the GUI handles the display and gives the illusion of 'container' for nested fields.
How does one implement parent-child with a simple list ?
It would mean the parent would have to somehow contain a copy to the child items. Limiting it to just one generation makes it easier than having a relational or flat linked model.
I think how fast nested fields currently work or will in the future will give an indication of how feasible parent-child will be. Nested fields is parent-child with just ONE field vertically.
Parent child is doing the same thing but horizontally ie adding more fields.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version