More > Media Center 14 (Development Ended)

Next -- Relational Database?

<< < (3/13) > >>

hit_ny:

--- Quote from: gappie on May 30, 2009, 04:34:38 am ---i also agree, just wanted to point out that there was already something like that.

--- End quote ---
Yeah, thx for that it goes to show that this functionality could be extended to be user configurable.


--- Quote from: gappie on May 30, 2009, 04:34:38 am ---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.
--- End quote ---

Let me explain parent-child in another way for those that still have not understood darichmans proposal.

All he's asking for is to be able to create user records.

To go from custom [Field] to custom [Record]

For a record like [Actor] to be able to hold child fields like [Bio], [Filmography], etc. But now [Actor] is a record instead of just a field and can contain other embedded fields in it.

Thats it.

When you import a movie that has the same actor then all you would do is select the actors name from the pulldown and assign it just like you do with [Artist] fields currently. The difference is that in addition to just the [Actor] name you would get the child fields along as well. End result is less repetitive work for media that has complex meta-data like movies or even classical music.

So you can see there is nothing relational about this suggestion at all and daresay its pretentious :D



--- Quote from: gappie on May 30, 2009, 04:34:38 am ---i use a lot of nested fields, i think they are still problematic.  ;)
--- End quote ---

Ah, i think you should start a thread about it then and give your suggestions.

I've used nested fields for record labels with audio and did not notice much problems.


--- Quote from: gappie on May 30, 2009, 06:03:52 am ---now .. i would love something like your 3rd item. and that is something that really calls for a relational database.

--- End quote ---
Simple way to do this is to convert [Last Played] into a list like field that contains the time& date of say the last ten times played.

darichman:
I would still like to see this.

Rather than posting again here, I'll point to a few posts which I think summarise potential endpoints well:

Functional Outcomes
Practical Examples
Potential Implementation

To briefly summarise potential advantages

1. Less repetitive work for the user - adding files to an existing entry in the database is much easier than re-entering the same values for the same fields each time I add new files.
2. This could solve the common request for Artist Coverart etc... each parent field could have an [Image] field as a child field.
3. Logical grouping of common concepts - in effect, we can easily group fields as they relate to common entities like [Artist] or [Movie]. Adding a file to a [Movie] immediately tells MC (and the user) a lot about the file.
4. Less ambiguity about some fields - using this approach, the user can easily tell the difference between tagging the year of a file, or the year an album was released.
5. Intuitive and useful artist/album/movie summaries might be easily created based on this info.
6. The entire concept is completely optional to the user... if they never assign child fields to parent fields - nothing changes and they continue to use MC as they have been.
7. Calculations across fields

hit_ny:

--- Quote from: gappie on May 30, 2009, 03:32:31 am ---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)).

--- End quote ---

yes and no. Logically they appear similar but functionally they are different.

The Album Gain example performs some calculations before assigning values to album gain. Currently its a hard-wired expression that works across files inside MC and is done during AA. I would like in the future to have the ability to define what grouping so it could be done automatically with expressions. Because it would allow expressions to automatically work 'across-files' in addition to the 'within-files-only' way right now.

So i think its different to parent-child or super-fields which is only a way to assign a previously entered, fixed value (rather bunch of values) to another. There is no calculation or additional processing on top nor is there any requirement to do so.

KingSparta:
I Have No Idea What A "Relational Database" Is

Is Not A "Database" Is A "Database"

What You Do With The "Database" After You Have A Database Is More Of A Program Function.

dcwebman:
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page