2 ms·
One of the simplest data model mistakes that seems nearly universal in music software is pretending that some things are single values when they're really lists
by SAI_Peregrinus 5y ago
One of the simplest data model mistakes that seems nearly universal in music software is pretending that some things are single values when they're really lists.
Take "artist". An album can have a compilation of tracks, each from a different artist. A given track can have multiple artists, eg a guest singer. There can be multiple composers of a track, there can be multiple writers of lyrics, and there are usually several performers (even if they all are part of the same band).
An album can have multiple names, or no name at all (which often means people refer to it in different ways, giving it multiple effective names). Likewise with tracks.
Albums and tracks get re-released, sometimes re-mastered, sometimes re-recorded entirely, without the names changing.
The same recording of a given track might be released on multiple albums, eg as a single in a pre-release and then within the main album.
Tracks might be mastered differently for different media (Radio vs CD vs background use in cinema, etc).
Names of any of these things don't have to be representable in any existing text encoding, or even any combination of encodings.
Artist name should be a list (or other multiple element structure).
Track name should be a list.
Album name should be a list.
Etc. Assume a malicious artist will find a way to make the assumption that any field has a unique value incorrect.
- wolverine876 5y ago> or other multiple element structure Right. It's a relational database with lots of many-to-many relationships. We need to stop trying to make it a flat file. A FOSS SQLite schema that everyone can embed, or even a turnkey little db, would be wonderful.