More > Media Center 14 (Development Ended)
Next -- Relational Database?
rick.ca:
--- Quote from: rick.ca on June 13, 2009, 02:42:37 am ---Understandably, I cannot "rename" anything in these ("[category] details") views. Would I be able to use the "Store this field per [category]" command?... Hmmm. For list values, I think not—that would require a relational database!
--- End quote ---
--- Quote from: darichman on June 13, 2009, 02:32:16 am ---The other foreseeable issue here is list fields... simple inheritance like this won't allow me to tag "Tom Cruise" in a file with [Actor] = Tom Cruise;Nicole Kidman unless there was another layer to this.
--- End quote ---
As much as I would like to pursue a feasible path, the inability to save additional information about list items is a rather huge limitation. I wonder if Matt's suggested approach is not akin to saying, "We can add relational functionality, as long as the subject is not relational."
The reason for my concern? Virtually all video category values I might want to record additional information about (all people, genres, series) are all list fields. My photos are organized by nested lists (places, people, keywords). The flat file accommodation of relations, for me, only seems applicable to music. And there, I'm with most other users—I don't care much about handling relations because the flat file model seems to work well enough. But I think that's just because I'm so used to dealing with music using that model. I can see how others may view music in exactly the same way I view movies—and have a real need to handle relations which cannot be handled in a non-relational model (I won't attempt to be specific, but it seems to come up frequently when knowledgeable users discuss the special requirements of classical music).
So unless I'm missing something (which is quite possible), I'll have to return to my original proposal. If something like that is not feasible, I think we should give up on the idea of MC handling relations in any significant way. Lest that be taken the wrong way, let me reiterate—as darichman has—my proposal is just an attempt to describe the functionality and behaviour I think would constitute a significant improvement/new feature. I'm not trying to suggest how the software should work, or if the concept is in any way feasible. That's for the developers to decide.
Matt's "Store this field per [category]" mechanism might be a nice enhancement, but I wonder if it's helpful to think of it as a solution to handling relations. The issues raised are difficult to assess, but my gut tells me they're likely more trouble than the enhancement is worth—particularly in the complexity it adds—even if implemented perfectly. Imagine a new user's response to a dialog box they have no reason to anticipate: "Why would I want to 'Save shoe size per album'?" As I said earlier, "I think the best approach would be to keep it simple, generic and intuitive." As much as I would like to see some relational functionality, I think it would a mistake to make any changes that violate this premise.
Matt:
--- Quote from: rick.ca on June 13, 2009, 03:12:41 pm ---As much as I would like to pursue a feasible path, the inability to save additional information about list items is a rather huge limitation. I wonder if Matt's suggested approach is not akin to saying, "We can add relational functionality, as long as the subject is not relational."
--- End quote ---
Wouldn't you just store the related data also in a list?
Imagine a list-type field "Actors" with a child field "Date of Birth". If the list of Actors were "Billy Bob Thorton; Tom Hanks", then the "Date of Birth" field would look like "1955; 1956".
leezer3:
--- Quote from: Matt on June 13, 2009, 06:34:27 pm ---Wouldn't you just store the related data also in a list?
Imagine a list-type field "Actors" with a child field "Date of Birth". If the list of Actors were "Billy Bob Thorton; Tom Hanks", then the "Date of Birth" field would look like "1955; 1956".
--- End quote ---
What happens if the field gets re-ordered though?
As far as I can tell, your proposal would completely rat things up if a new value was added in either of the two fields without a corresponding value added in the other. (Feel free to prove me wrong!)
-Leezer-
Matt:
--- Quote from: leezer3 on June 13, 2009, 06:54:07 pm ---What happens if the field gets re-ordered though?
As far as I can tell, your proposal would completely rat things up if a new value was added in either of the two fields without a corresponding value added in the other. (Feel free to prove me wrong!)
-Leezer-
--- End quote ---
I would think a set to the parent or child field could automatically update the other. Again, it slows down database sets on these fields a little, but I don't consider that a big problem.
rick.ca:
--- Quote from: Matt on June 13, 2009, 06:34:27 pm ---Imagine a list-type field "Actors" with a child field "Date of Birth". If the list of Actors were "Billy Bob Thorton; Tom Hanks", then the "Date of Birth" field would look like "1955; 1956".
--- End quote ---
Sorry, I'm confused. Isn't "child field" part of the concept proposed by darichman? I probably need to study that again, but I'm pretty sure it's a "quasi-relational" solution which, aside from jargon, is similar to mine. Maybe I'm wrong, but I don't think it works without changing the existing architecture either.
Maybe if I understood the ramifications of your example... Would I be able to create a view of actors and their dates of birth? Would I be able to add, change and delete them using this view?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version