* buy a 1-big-table log aggregator like SenSage
(http://www.sensage.com) (distributed Linux-based
redundant large data storage/query engine)
* define a single DB table with the media_UID as
key and with all columns defined for all related
objects (note: I'm assuming fixed-column-set
for each "related object") ... with the understanding
that any given row may or may not contain a
"related object" of a given type
* I'd take the (relatively) static data for each
media file (e.g., media_UID, file size, file name,
media type, ..., # of unique faces recognized in
the media, make-up-your-own-field-here) and
insert it once, with NULLs for other dynamic
"related object" fields
* For dynamic info I'd insert media_UID and relevant
fields and a timestamp for the dynamic event
* ... and after this you'd have a queryable data set
that's constantly evolving
* you could dynamically update the schema as you need
more "related objects" or more extend their fields
This is very important for its native purpose, log data storage. For legal reasons companies that store logs related to HIPAA (health care records), SOX (public company financial records), CDR/IP-R (call-data/IP), PCI (Payment/Credit/Debit card data) need to keep records about what went on with their routers/switches, computers, servers, apps, so they can reconstruct a cross-device slice of any activities of interest for legal purposes. (It's also useful for maintaining operational integrity and proving SLAs).
In this context here of media-related storage, not throwing data away has some nice advantages in that you can always track the evolution of all interaction with the media over time. (e.g., capture media download trends ...) Then engine can store it all. Many users load 200GB+ daily of log data into the data engine.