More > Media Center 14 (Development Ended)
Next -- Relational Database?
rick.ca:
--- Quote from: Matt on June 12, 2009, 07:34:13 pm ---So in a way, you're saying you want to create a blob of information. Maybe that blob is a biography, maybe it's actor information.
Then you want to link that blob to files either manually or by some rule like "artist is aerosmith" or "actor contains billy bob thorton"?
--- End quote ---
I am the one you quoted, and I don't know if "bingo" is the appropriate response. ;)
The term "blob" scares me, because I believe it actually means something in connection with relational databases. I prefer to call it a table, related by a common value in a specific media record category and that in the table's "key" column. I'm not suggesting how that might work—just that from a user perspective the "link" would be made by the values being equal. Having established this link, the user could add whatever additional fields necessary (bio, birth date, shoe size, etc).
Also, I'm not just looking for something that will facilitate the storing of common information in a media file database. In most cases, the related table I'm talking about would be of some significance to me all by itself. For example, a table of artist biographical information, a table of photo album date/travel/geographical information, a table of music style descriptions, etc. I would want to be able to browse and maintain these tables in their own views.
--- Quote from: Matt on June 12, 2009, 04:37:14 pm ---When a value is changed, it would be changed for all others in the relationship. This would be a relatively straight-forward addition to the database.
--- End quote ---
After my previous, rather long-winded response, it occurred to me I hadn't commented on what may the most important part of your message. This sounds very encouraging, but might also imply a limit to what you believe is feasible—as an "extension" to the current database/program. Not knowing the "mechanism" you refer to, it's difficult for me to imagine whether it might be adapted to provide the functionality I'm describing. I'm also not sure whether our ideas about this are fundamentally different, or just different perspectives of the same thing. I suspect the answer to that is somewhere in between. :-\
I'm trying to stick with my non-technical definition of "relational" (a method of organizing data in a database so that it is perceived by the user as a set of tables) but I suspect my suggestion actually involves the "additional information" being saved in what is "physically" a separate table. Do you think that's true? If so, is it feasible? I realize there must be performance issues, but it seems to me those will cut both ways. First, it's optional—it won't have any impact unless used. Considering the nature of "additional information," it may be a way to separate seldom used information from the main media record database so it doesn't have to be involved in all processes. I know I don't understand all the technical issues. A premise of my idea, I suppose, is the notion information like an artist's bio is surely more efficient to "look up" when needed. If it's not like that, maybe it should be saved in the usual manner (e.g., so it's always readily available in media record views).
newsposter:
Blobs aren't all that scary. Unless you try to embed them in database tables.
A proper blob implementation (as Oracle learned to the pain and suffering of a load of users back in the mid 1990s) can be thought of as meta-meta-data.
User-field points to blob-meta-data points to external file.
Note that this is much the same way that music and cover art 'data' is referenced. We now allow things like RTF, PDF, XLS, ODF, and TXT files to be attached. The definition of these blobs also passes along certain characteristics to the skinning API to make it very easy to 'play' (display) that text and graphics data in a device/screen independant way.
rick.ca:
--- Quote ---Blobs aren't all that scary. Unless you try to embed them in database tables.
--- End quote ---
Or think of the 1958 movie ("an alien life form consumes everything in its path as it grows and grows"). ;)
After reading the Wikipedia entry for blob, I thought perhaps it is a fitting term for what I've awkwardly been calling an "additional information record." Especially if it is to be handled as such in a table separate from the main media file table. All that matters to the latter is the relationship itself—that there is additional information in the blob. The additional information could be anything, and it doesn't matter to the normal operation of the database what that information is. It is, of course, made up of user-defined fields, but these are of no consequence to a media file view unless referenced by an expression.
If the "blob table" idea is feasible, it will be important to recognize any field currently part of the media file database, with the exception of the media file path, could be handled handled as part of a blob. Calling it a blob emphasizes the fact that, for many fields, this would not be a good idea. Any field regularly used for searching and sorting media records should not be in a blob. So I might create an artist blob for biography, date of birth, country of origin, and date of death. That might be fine, but if I like to sort or group my media by country, perhaps it should be part of the media record instead.
This idea is becoming clearer to me (the concept—not whether or not it will work). Now all I need is for darichman to show up to explain parent vs. child blobs, and whether blobs are containers or things needing containment. ;D
newsposter:
Calling database 'piles' like that came from Oracle. Binary Large OBjects.
When I say that Oracle learned on the back of it's users that embedded blobs are not a good idea I mean it. Oracle 8 and it's initial implementation of blobs just about brought the company down. Of course, when they fixed it Larry Ellison became a basillionaire, but it was a near thing for about a year.
Database records are supposed to be small and granular. Blobs are anything but.
'Inventing' a decent, redundant, recoverable repository for blobs might be a good idea. It might already have been done in the many content management systems out there. But lets keep the hugeness external, not internal to the database.
Matt:
--- Quote from: rick.ca on June 12, 2009, 11:48:47 pm ---Any field regularly used for searching and sorting media records should not be in a blob. So I might create an artist blob for biography, date of birth, country of origin, and date of death. That might be fine, but if I like to sort or group my media by country, perhaps it should be part of the media record instead.
--- End quote ---
That sort by country bit is an argument in favor of the first approach.
If you make fields "Biography", "Date of Birth", "Country of Origin" and "Date of Death" and set them to be stored per artist it would be easy to use the fields in searches, for sorting, etc.
Since you can make a view that groups by artist, you would effectively be able to look at the table of "Biography" values just by using such a view.
I like that this approach fits nicely with the existing architecture and doesn't introduce any performance penalty in normal usage. (sets of relational fields would be a little slower, but sets are not too common)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version