-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Normal
-
None
-
Affects Version/s: None
-
Component/s: Schema Change
-
None
Currently our ISWC and ISRC tables store ISWC-work and ISRC-recording pairs, respectively. This means that even though we have pages such as https://musicbrainz.org/isrc/USSM19932777 (that can list multiple codes), there isn't one DB row nor one DB id for this ISRC.
This is blocking MBS-7406 and would in general make our DB structure match the way we actually think about and use the codes.
We should move the work and recording association out of the ISRC and ISWC tables, and onto their own iswc_work and isrc_recording tables.
It would probably involve something like moving from:
CREATE TABLE isrc ( -- replicate (verbose)
id SERIAL,
recording INTEGER NOT NULL, -- references recording.id
isrc CHAR(12) NOT NULL CHECK (isrc ~ E'^[A-Z]{2}[A-Z0-9]{3}[0-9]{7}$'),
source SMALLINT,
edits_pending INTEGER NOT NULL DEFAULT 0 CHECK (edits_pending >= 0),
created TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);
to the combination:
CREATE TABLE isrc ( -- replicate (verbose)
id SERIAL,
isrc CHAR(12) NOT NULL CHECK (isrc ~ E'^[A-Z]{2}[A-Z0-9]{3}[0-9]{7}$'),
edits_pending INTEGER NOT NULL DEFAULT 0 CHECK (edits_pending >= 0),
last_updated TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);
CREATE TABLE isrc_recording ( -- replicate (verbose)
isrc INTEGER NOT NULL, -- PK, references isrc.id
recording INTEGER NOT NULL, -- PK, references recording.id
last_updated TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);
Since both tables are mutable (one has edits_pending and the other will change on recording merges) last_updated seems more appropriate than created, so we change that (they could start by keeping the created date of the original table for the association, and the latest created date of any associations with a code for the code table). edits_pending seems best to keep on the code since the code is what we generally highlight if there are any pending edits even now.