3つのテーブルの多対多の中間テーブルのベストプラクティス

議題への理解にも自信が持てないし、ベストかどうかも解らないのですが、賑やかしに、自分ならどうしたいかを書いてみます。
的外れでしたら申し訳ありません。

• DBの要件に対しては次のように解釈しています。
  • Usersは楽曲の利用者ではなく、音楽家(アーティスト)である。
  • Musicはスコア(総譜)であって、音源ではない。
  • 一人のメンバーが、同一あるいは異なる楽曲において、複数の役職を担いうる。
  • 一つの楽曲に同じ役職の異なるメンバーが参加しうる。
• 案1
  • ここで示されているValidateとは、本来テーブルにすべき情報を、プログラム上のデータやコードにするか、カラムの制約としてハードコーディングするか、FileMakerの値一覧のような別のテーブルにするなど、別の形で持つことなのではないかと思います。
  • 役職が三つ(作曲、編曲、作詞)だけで増える可能性がないなら、それでもいいのかなと思います。
• 案2
  • 役職という属性が多種の値を持ちうるのですから、役職のテーブルを用意することは自然に思えます。
  • 例えば、「実は楽曲が音源で、歌唱、演奏、指揮、楽器毎の奏者など、さらに多くの役職が必要になって…」などと考えると、やはりテーブルを作りたいです。
  • 「ORMでの操作が複雑化する」懸念は、ビューとかプログラムとかででなんとかする(してもらう)ことにして、DBのデザインを優先したいです。
• 案3
  • 案1は、後から案2にすることも容易に思えますが、案3は後から苦労しそうで、この題材であれば使いたくないです。
• 案0
  • 最後の要件がない(=一つの役職に一人ずつ)ならば、Musicにcomposer_idとかを用意して直結することも考えられます。
  • 実際にそれで作ってしまった後で必要になって、仕方なく複数アーティストのユニットとして登録してごまかすようなことがありました。

@tetr4lab
回答ありがとうございます！
とても分かりやすくて参考になりました。

「ORMでの操作が複雑化する」懸念は、ビューとかプログラムとかででなんとかする(してもらう)ことにして、DBのデザインを優先したいです。

この考え方はすごく良いなと思いました。その方が後々面倒なことにならなそうですね。

最後の要件がない(=一つの役職に一人ずつ)ならば、Musicにcomposer_idとかを用意して直結することも考えられます。

これは全く考えれていなかったのですが、そもそも多対多なのか、ということはしっかり考えないといけないのですね。