# Presence or absence of mould SID enough to have separate releases?

**URL:** https://community.metabrainz.org/t/presence-or-absence-of-mould-sid-enough-to-have-separate-releases/362245
**Category:** Style
**Created:** [February 25, 2018, 1:53pm UTC](https://community.metabrainz.org/t/presence-or-absence-of-mould-sid-enough-to-have-separate-releases/362245 "2018-02-25T13:53:11Z")
**Posts on this page:** 1
**Showing post:** 6

<div class="post-metadata">

### Author: ![spitzwegerich](https://community.metabrainz.org/letter_avatar_proxy/v4/letter/s/aca169/32.png) [@spitzwegerich](https://community.metabrainz.org/u/spitzwegerich)
#### Post date: [March 9, 2018, 7:53pm UTC](https://community.metabrainz.org/t/presence-or-absence-of-mould-sid-enough-to-have-separate-releases/362245/6 "2018-03-09T19:53:16Z")

</div>

So you want to link your releases against discogs and musicbrainz, and you expect that there must be a 1:1 assignment. What I don’t like is that apparently you take it as granted that this always must be possible.

At the [discussion](https://community.metabrainz.org/t/alternate-cd-matrix-runout-inscriptions-enough-for-a-new-release/79829) Freso gave us you see that there is not a broad agreement on when two releases should be separated in musicbrainz.

Actually, I think there should be some limit on which minor differences indicate to create a new release. Adding a new release for each minor difference in the mould SID might result in an insane number of releases and massive data duplication (which always indicates a bad database design).

But I recognize that there is some interest in the differentiation of those minor production details. I think the best way would be to introduce a sub-release entity “production variant” (or whatever) for keeping track of those. The discogs link could then be set on release- or on variant-level, depending on the data state on the discogs side.

---

_[View the full topic](https://community.metabrainz.org/t/presence-or-absence-of-mould-sid-enough-to-have-separate-releases/362245)._
