MusicBrainz Database/Schema

From MusicBrainz Wiki
< MusicBrainz Database
Revision as of 11:21, 16 March 2007 by LukasLalinsky (talk) ((Imported from MoinMoin))

Simplified NGS

There is a lot of ideas about NextGenerationSchema. Unfortunately the resources to implement them are limited, and complex models like ObjectModel, TrackGrouping and AlbumRework are probably not going to happen in near future. So, I've decided to simplify these proposals to implementable shapes and then try to start working on them.



This the most abstract entity, a musical work. In terms of TrackGrouping, it can represent songs, composition, arrangements, recordings and mixes. Works can be interlinked with AdvancedRelationships (covers, remixes, ...).


Track is a work on a specific release and can have attached PUIDs and TRMs. Tracks will have no AR types, all track ARs will be transparently added to works instead.


This is what MB used to call "album", now "release". It's simply a list of tracks and can have attached DiscIDs. This entity will only visible as a part of a release, never on it's own.


Release is a set of discs, with date, country, label and catalog number. MB currently calls it "release event" and it's linked to "discs", but the other way around. Instead of the current "disc A was released on X and Y" and "disc B was released on Y", it will be "release X contains disc A" and "release Y contains discs A and B". The relation between discs and releases contains information about disc number, title and format (e.g. it's possible to use single disc for both vinyl and CD releases). A release can't have multiple "release events" -- if it has a different catalog number, it's simply a different release.


Album is a group of releases. This can be used link all editions or re-releases of an album, maybe also for series of compilations, etc.

Proposed Roadmap

  1. Checkmark.png Add label, cat# and barcode fields to release events.
  2. Remove the albumjoin table. This is technically not necessary, but we don't need N:M relations here and can save the DB load for other new features.
  3. Add the "Work" entity (table work).
  4. Add table album_release to allow N:M relations between discs and releases.
  5. Reverse the meaning album_release and make releases the primary entities on the website.
  6. Add the "Album" entity (table album2).

Database Schema

The new schema is actually not very different from the current one. The main difference are two new tables "work" and "album2" (I wanted to avoid renaming of existing tables) and reversed relation between tables "release" and "album".


Here is a version with renamed tables:

ngs fixed.png


Why is there an artist column in WORK? --davitof 2007-03-16

  • Because I think WORKs should be assigned to artists. Not all WORKs have to be linked to TRACKs, so we need a way to determine the artist
    • As usual, I wasn't clear enough. I meant: aren't there cases where there is more than one ARTIST and shouldn't the artist(s) be linked to the work by a 1-n relation? Here I feel that NGS is not precise enough. Using 1-n relations would avoid creating ARTISTs for collaborations more often than when they are really historically meaningful. Furthermore, it would allow to make the ARTIST - WORK relation more abstract: an artist may have composed, written the text, arranged... the work. OTOH, your NGS proposal is identical to the current MB schema, so my question can be for a future evolution.
      • The idea is that the ARTIST column for WORK/TRACK/RELEASE/ALBUM is a "label" - it doesn't specify who did what, only who it's usually credited to. If the single artist column is not enough for this, then I'd rather drop it at all. For more detailed ARTIST - WORK relations we have ARs. I don't think we need to duplicate them and implement one more "generic" linking system. Btw, there is some more info about this on GettingRidOfFeaturingArtistStyle. After thinking about it, I'm starting to like this solution again... And yes, DB-wise is the schema very similar to the current one. But a big difference is the presentation layer. My primary goal is to avoid duplication: * If a TRACK appears on N DISCs, there is no need to add "composed by" ARs to each of them. * If two DISCs are released on one RELEASE, there is no need to have two RELEASE entities, each attached to each disc.


I suggest renaming RELEASE to something else to avoid confusions with the current release concept in MB (I know, there has already been a discussion about what term should be used for this) --davitof 2007-03-16

  • I don't think there will be much confusion. "release events" used to be called RELEASE, in database and the server code still are called that way, and in fact are releases. The only problem is in the way they are linked to DISCs. --LukasLalinsky