Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Total DC noob here, looked for high-level getting started, database-design type docs, apparently none out there? In looking through the help and messages here, I'm still not clear on how to approach what I'm trying to accomplish.
I'm looking to organize my Grateful Dead music collection. The master lossless tracks are tied to a single given "album" in a standard many-to-one relationship - albums may be of type "show" or "studio" or "compilation" or "retrospective".
I'd like to tie the derived files - different sized MP3s - back to their master canonical lossless track, another many-to-one relationship.
However - this is where the many-to-many comes in - I'd also like to "substitute" a given MP3 for the basically-identical song that may be featured in several different "albums" - there are many different re-masters of a given show, and the same track may also feature on a later compilation or retro album. I'd also like to create user-playlists separate from the published albums.
I'm guessing maybe I should try to use DC's "containers"? In some locations I've seen that these (apparently now?) accommodate a given track to be assigned to multiple parents? Is there a way for different order-numbers to be assigned for a given track, unique to each container?
I'd also be willing to investigate creating a custom module type if that's required, suggestions on how to proceed to accommodate the above needs would be greatly appreciated.
Or if DC won't be able to handle this do please let me know, as I'd like to save what looks like a pretty steep learning curve to get started.
Hope y'all don't mind my talking to myself here to track the evolution of my thinking, feel free to chime in with DC-specific info may be helpful in the future to others.
Here's an outline of my current thinking. Could possibly combine MasterSourceInstance and Playlist, but the former has a lot of data points that would just be empty fields for playlist items.
(may) come from (only one)
is an instance of (usually only one, but possibly more when "songX>songY" is not split)
is a member of (more than one)
is an instance of (only one)
OK, making progress, actual hands-on experience with Data Crow, getting to know it a bit better, but so far only don't real-life data-entry on one table, just noodling the database design part as an abstract thought exercise, continuing to document my thoughts here just in case someone's willing/able to give constructive feedback, or possible will be of use to others googling later on.
I definitely think "Shows" and "albumForm" as abstract entities should be separate modules rather than differentiated by values in the same one, Shows just have so many fields that should be required there but just aren't relevant to albums, and since there are quite a few released "show album" (1:1 relation) as well as compilation albums that have featured music from different shows (many:many), it seems more likely I'll be able to use multiple reference fields between items in different modules, more straightforward than between items in the same module (confirmation please?)
I've successfully made use of db.etree's "personal collection" database feature to export the Show details to CSV and bring them into my Shows module, then added artwork for disc covers, show posters, tickets, flyers etc, very cool! Also stored links back to deadlists, deadbase (got the YearRank and TrackRank survey results too), links to reviews on some of the more prominent discussion sites, etc. My key fields to avoid duplicates are the key values used for lookups at etree and deadbase.
For the songs, it seems like I'll need two "abstract objects" before getting down to the actual track files themselves. At the highest level "songForms" are just a property module listing standardized titles of all songs ever performed by the Dead, pretty straightforward import.
Then "songInstance" will be used for noteworthy "instances" of a given songForm, featured on an albumForm or performed on a given Show date. These will provide many-to-many relationship/reference fields (I believe these two terms are used in DC's docs for the same concept right?) where a given songInstance was both performed as part of a Show and featured on an albumForm, either a "showAlbum" or a compilation. This should help me to create compilation Playlists/Collections that recreate a given Show using professionally re-mastered songInstances from published albums where they're available, and the lower-quality soundboard or even audience recordings for those that weren't published.
Even if a given song only exists as part of a single Show or Album, I'll create a songInstance item for it if it's a notable performance, perhaps candidate for a "best version" listing for a given songForm.
For actual collections of files - "sources" - I'll just use the Music Album module. Or perhaps make a copy of that and the tracks module specifically for my Dead collection, leaving the original built-in DC modules for use for other artists, where I don't have such complex requirement.
If I do use a copy of the original MA module rather than the built-in one itself, that will give me the option of perhaps making both a "showSource" and "releasedAlbum" module, in order to take advantage of the built-in parent-child relationship to their respective "Shows" and "albumForm". This seems to fit, since any given collection of files (Music Album item) will have one and only one parent, either a Show or a released Album.
Or I just use the built-in Music Album module for everything, and use multiple-reference fields to link them to their parent stored in one module or the other (Show vs albumForm).
Feedback on the advantages/disadvantages would be welcome - I shudder at having to learn XSLT to create reports on this stuff 8-)
Note that the lossless SHN/FLAC files will be separate items from the MP3s, and in fact I may need to have smallMP3s for mobile gadget use, and large ones when playing from the computer.