MusicBrainz Database/Schema

From MusicBrainz Wiki
< MusicBrainz Database
Revision as of 09:54, 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 --LukasLalinsky

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