After reviewed some of the prolific darichman posts on the subject, I'm somewhat less confused. At a conceptual level, his
Parent field, with a set of
Child fields, is a
Table—according to my working definition of
Relational. As far as that goes, we're talking about exactly the same thing. There are some differences in how we see various types of relations being handled, and in how they should manifest in the UI. Darichman seems to favour building relational functionality into the existing media-centric view, while I prefer to see it as a somewhat more independent extension (e.g., I would like to be able to work directly with my "tables"). That difference is less than it may seem, because I define the relationship to my "additional information" table as being "one-way." It can be referenced from the media view, but referencing media from the table view is not required.
So I'm less confused, but more concerned about where this conversation is headed. It seems to be taking a familiar circular form, like the ones before it. So I wonder, why do these conversations go nowhere when the concepts being floated are so straightforward. I think it's because of our (yes, mine too) fixation on the media-centric view of the database. There's nothing wrong with that—it quite obviously goes hand-in-hand with some of the fundamental strengths of the program we all appreciate. But it also gets in the way of rational consideration of additional features.
So this is what seems to be happening: No one wants a new feature/functionality to "break" the existing architecture. So we naturally look for ways to incorporate new ideas into the existing structure. So we look at the proposal, and twist it and turn it inside-out so it conforms to our existing view. Matt eventually tells us things like "it already does that," or "we can easily extend it to do that." Unfortunately, much of the anticipated benefit of the change is lost at this point. This should be no surprise. The existing architecture is mature, highly refined and performs extremely well. Any attempt to incorporate "more" into the same model it likely going to end up at the same place—not discernibly closer to perfection.
So we end up talking endlessly about things like "inheritance." We don't have an inheritance problem now—so who cares? When I pondered that one, I came to conclusion I really don't want any inheritance going on. Once I've established an artist table that includes a bio, for example, why would I want to even consider overwriting the bio with a tag from a new track? Obviously, my source for the artist bio is better known, accurate, reliable, and/or simply what I want. That's probably the reason I established the artist table in the first place. And I still may want to keep the bios in/from the media tags. It's fine to provide a facility to write a media field/tag to a table field, but making them the same just diminishes the value of the feature we're proposing.
And then there's list fields. It amazing how well MC handles these. For my 800-item video collection, there's over 13,000 people in one name\career\role nested field. It's very cool. But I can't record any additional information about these people! Obviously, I don't want to record information about all of them. And this is my point—for satisfying my desire to record information about some people related to some videos, the media-centric view becomes irrelevant. What makes a lot more sense is the ability to add a relative handful (perhaps a few hundred each of my favourite directors and actors) to a separate table (I'm sure we could call it a "view") and those be "linked" in various ways to the occurrences of those people in the media view.
By trying to crunch relational functionality into the media-centric flat-file view only diminishes the potential value of this as a feature, while making the existing model even more confusing and intimidating than it already is. I think it would be better to implement something of a truly relational nature, rather than trying to bury and blend it into the current non-relational model. Imagine how the program might then be introduced to the newcomer...
"Welcome to Media Center. It provides a media-centric view of all your media files because, well, it's a media manager! You can record as much information as you like about each of your media files. MC will keep all that information organized, up-to-date and properly associated your media files. It will do so with blazing speed, for more files than you can dream of owning. Now, if you want to record any additional information not directly related to a specific media file (e.g., an artist's biography), just right-click on any entry (in this case, an artist) and select
Add additional information. That will open a separate view where you can add a column and enter the information..."
Okay, a marketing person would say it better, but I bet most would be impressed. By
not integrating the feature so tightly into the existing model, it stands out as an intuitive, useful, substantive, additional feature. And there are more advantages:
- Completely optional, and unobtrusive if not used.
- Minimal impact on the existing structure, function and performance.
- Does not further complicate the core functions of the program.
- Allows a way of maintaining additional information so it's not impacted by changing media files.
- Allows information not directly related to media files to be entered, maintained and viewed in more intuitive, direct way.
- Provides more flexibility in collection design—fields can be related to media, another category, or both.
- There's more, but this is already longer than a darichman post!
Author
Topic: Next -- Relational Database? (Read 16073 times)