音楽の味を共有するWebアプリケーション用のデータベースを設計しようとしています。
私はDb設計/アーキテクチャを行う必要はほとんどなく、SOユーザーから助けを得ることができると思いました。私の質問が、「優れた」Db設計手法の良い例になることを願っています。
参考：ERDは、無料のソフトウェアであるMySQLWorkbenchを使用して作成されました。
これらは私の要件であり、Dbスキーマでそれらをどのように表現したかです
ユーザーは資格情報とアカウント/プロファイル（電子メール、fName、lNameなど）を持っています-これはすべて
USER_DETAILSテーブルの下にありますユーザーはロールを持つことができます＆＆複数のユーザーが同じロールを持つことができます-したがって、＆テーブル間の多対多の関係
USER_DETAILSROLEユーザーは画像を持つことができます-したがって、＆テーブル間の1対多の関係
USER_DETAILSUSER_IMAGEユーザーは多くのバッジを持つことができ、複数のユーザーは同じバッジを持つことができます-したがって、＆テーブル間の多対多の関係
USER_DETAILSBADGEユーザーのトラックには多くのレピュテーション履歴を含めることができ、レピュテーション履歴は1つの特定のユーザーのトラックとのみ一致します。したがって、＆テーブル間の1対多の関係です。
USER_DETAILS_TRACKREPUTATION_HISTORYユーザーは多くのトラックを持つことができ、複数のユーザーは同じトラックを持つことができます-したがって、＆テーブル間の多対多の関係
USER_DETAILSTRACKユーザーはトラックごとにタグを持つことができ、複数のユーザーはトラックごとに同じタグを持つことができます-したがって、＆テーブル間の多対多の関係
USER_DETAILS_TRACKTAG_2トラックはhas
TRACKテーブルの下に表示されますトラックには複数のアーティストを含めることができ、アーティストは複数のトラックに含めることができます-したがって、＆テーブル間の多対多の関係
TRACKARTISTトラックには複数のリリースを含めることができ、リリースには（＆通常）複数のトラックを含めることができます-したがって、＆テーブル間の多対多の関係
TRACKRELEASEリリースには1つのrelease_typeがあり、release_typeは多くのリリースに含まれる可能性があります。したがって、＆テーブル間の1対多の関係（リリースタイプはアルバム、EP、LP、シングルなど）
RELEASE_TYPERELEASEトラックにはコメントを含めることができます-したがって、＆テーブル間の1対多の関係
TRACKCOMMENTトラックには複数のタグを含めることができ、アーティストは複数のトラックに含めることができます-したがって、＆テーブル間の多対多の関係
TRACKTAG_1
TAGテーブルにTAG_1とTAG_2が含まれていることを複製したことに気付いたはずです。USER_DETAILS_TRACK理想的には1つだけですが、テーブルはすでに多対1の関係にTRACKリンクされているため、テーブル間の結合が強すぎるのではないかと心配しています。
中間層でTAG_1とTAG_2の同期を維持する予定です。
podiluskaのコメント後の最新の編集
- 私は自分のデータベース設計に関して正しい道を進んでいますか？
- 何を変更/改善しますか？
どうもありがとう