More > Media Center 14 (Development Ended)
Next -- Relational Database?
JONCAT:
--- 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 ---
Various pressings/masterings exist in excess in my archives...this occurs especially with "collectible" material.
DC
raldo:
I did a text search on "slow" in the previous posts. No one seems to mention this when talking about relational databases.
If you want "fast" when dealing with relational databases, you definitively cannot use any of the off the shelf client/server software out there. You'd basically have to reinvent your database and the access API.
JimH:
Not to throw cold water on this or anything, but...
We like the MC database. It's fast and reliable and tuned for media.
We may extend it in the future in ways that are useful to you, but replacing it isn't even a remote possibility.
I don't think many people appreciate how solid and smart it is.
rick.ca:
--- Quote ---Not to throw cold water on this or anything, but...
--- End quote ---
I don't take as "cold water," but necessary clarification—one which encourages me to rejoin what has been a draining conversation... :-\
--- Quote ---We may extend it in the future in ways that are useful to you, but replacing it isn't even a remote possibility.
--- End quote ---
I've never doubted this is where you stand, or considered questioning the wisdom of this. And it was with this in mind that I attempted to describe a concept which might be feasible as an "extension" to the current architecture. (I did so in a series of posts, but this one might be a reasonable starting point for anyone who is interested.) To sum it up, it's simply involves adding a new kind of record that would contain whatever information a user wanted to record about specific values used in their media record categories. The record, for example, could be for a name ("value") of an artist ("category") to which the user could add things like birth date, biography, etc. Media records would be associated by virtue of a particular "value" in a particular "category." This would be enough to "link" these "additional information" records so: (1) they appear in a second view when the corresponding value is selected in a media record; (2) the additional information could be incorporated into the media record via expression columns.
I think the preceding paragraph might have been much less painful had I been permitted to use the word "relational." The definition of this word I believe is most useful for this conversation is: relating to, using, or being a method of organizing data in a database so that it is perceived by the user as a set of tables. This permits the use of the word in describing database behaviour or results that might be desirable for users (e.g., "I would like to be able to record an artist bio without having to copy it to each media record associated with that artist.") It doesn't say or imply anything about database architecture.
So, MC is never going to be built on a relational database engine. That means there will be many "relational" things it will not be able to do. But it already handles some relations—even more efficiently than a relational database would. So it's not difficult to imagine it could be extended do more. I think users are being asked what sort of relational functionality we would like to see, so the developers can consider what might be done. If we were able to do so, maybe they could provide some feedback about what is feasible from a technical point-of-view.
JimH:
Rick,
I appreciate your thoughtfullness, in this and previous posts.
Jim
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version