類似データの正規化データベースと非正規化データベース

Question

私は音楽に関する大量のデータを保存するデータベースを構築する予定です。 私は曲に関する情報をdb_songテーブルに保存しています。 私はまたジャンル、楽器、サンプルとプレイリストを保存したいと思います。 1曲は複数のジャンル、楽器、サンプルやプレイリストを持つことができるので、大きな問題は、次のとおりです。

1. ストア別々のテーブル内のすべてのこれらの4つのデータ
2. ストアすべて：

   それは、より理にかなっています別の列でこれらの単一のテーブルで4つのデータ、および記録タイプ

データベースが頻繁に更新されますが、ユーザーがさらに頻繁にデータを要求します。

ありがとうございました。

編集：

アミットによって示唆されるように、上記の設定で、重複データの多くが存在することになります。 別の3つのテーブルで、ジャンルと楽器の値とプレイリストのタイトルを別のテーブルに保存し、ジャンル、楽器、プレイリストの関係（アイテムを曲にする）についてはどうでしょうか。ストアアイテム・ツー・歌の関係に

1. ストア別々のテーブル内のすべてのこれらの4つのデータ+ 4つの以上のテーブル
2. にストア内のすべてのこれらの4つのデータ：

   だから、新しいシナリオシングルテーブル、レコードタイプ別の列に+別の列の曲との関係

Answer 1

「曲」は、ジャンル、楽器、サンプル、プレイリストのそれぞれ0個または1個以上を持つことができます。だからではないテーブルが5つ未満であることを意味する。

さらに、これらの多くは「多対多」です。たとえば、1つのプレイリストには多くの曲を入れることができます。 1曲は多くのプレイリストに入れることができます。このような処理を行うには、多対多の関係を確立するために、song_idとplaylist_idを持つ追加のテーブルが必要です。

一方、「ジャンル」はおそらくダースの可能性のセットです - 「ロック」、「クラシック」...ジャンルのテーブルは必要ありません。代わりに、各曲（および各プレイリスト？）には、そのジャンルのENUMまたはSETを含めることができます。そして、多対多のマッピング（この場合）を持つことは価値がありません。

スキーマを完成させるには、SELECTsの外観を考えてください。

Answer 2

「大量のデータ」と言うと、どのくらいのデータが意味ですか？数百万曲と関連するメタデータは、標準のデータベース設定で実際のパフォーマンス上の問題を引き起こしてはいけません。

データベースを第3正規形（3NF）で設計し、4つ以上の別々の表を使用することをお勧めします。正規化されていない構造（1つの大きなテーブル）では、行に重複した情報があり、更新は正規化された構造と比較して高価になります。

データ読み取り/分析に関する要件では、履歴データ要件を伴う複雑なデータ分析の要件がある場合、運用システムの上にデータウェアハウスを構築することを検討する価値があります。データ要件が単純な場合（特定の曲、アーティスト、ジャンルの情報を得るためにこれらのテーブルを結合する場合）、正規化されたデータベースはそれらを快適に応答できるはずです。