0

私は小さな音楽ウェブサイトを開発しています。私はフロントエンドの開発者ですが、データベースについて十分な知識がありません。このウェブサイト用のデータベース設計を思いつきました。それを改善するために提案できますか？

私もいくつか質問があります..

  • 1 つの曲に対して複数のアーティストをサポートするように変更するにはどうすればよいですか?
  • song テーブルにアルバムを入れてもいいですか、それとも別のテーブルでなければなりませんか? 保存したいアルバムは他にないと思いますが、曲テーブルにアルバムを入れるのは非現実的でしょうか?

どうもありがとう。

ここに画像の説明を入力

4

3 に答える 3

2

頭のてっぺんから、私はおそらく次のようなものに行きます：

ここに画像の説明を入力

このデータ モデルには、次の特徴があります。

  • 曲とアーティストの間には多対多の関係があります (中央の「リンク」テーブル: SONG_ARTIST によって実装されます)。
  • アルバムは別表にあります。アルバム名だけが必要な場合、これは特に重要ではありませんが、後でさらにフィールドが必要になると思います。
  • SONG_NAME と ALBUM_NAME は、それぞれのテーブルのキーではありません。同じ名前を共有する複数の曲 (またはアルバム) が存在する場合があります。
  • 一方、GENRE_NAME は (代替) キーです。
  • ARTIST_NAME を代替キーにするかどうかは疑問です。私のモデルではそうすることにしましたが、これには、実生活でたまたま同じ名前を共有しているアーティストの識別名を「発明」する必要があります。おそらくより良い方法は、生年月日または生年月日も要求することですが、これにも潜在的な問題があります...
  • PLAYLIST_NAME はプレイリストのプライマリ キーに含まれているため、1 人のユーザーが複数のプレイリストを持つことができます。PLAYLIST には「子」関係がないため、「PLAYLIST_ID」などの代理キーを導入する必要はありません。
  • プレーンな PASSWORD の代わりに、PASSWORD_HASH と PASSWORD_SALT があります ( 「レインボー」攻撃を阻止するため)。
  • 命名規則では、エンティティ名に単数形を使用します。これは、こちらで確認できる推奨事項とより一致しています。
于 2012-04-23T19:18:02.743 に答える
1

1 つの曲に複数のアーティストがいる場合、各行にその曲のアーティストの songID と artistID が含まれる個別のテーブルを作成できます。そのため、複数のアーティストを含む曲の ID には、それぞれの曲 ID を含む行があります。アーティスト。典型的な N 対 N の関係構築。

アルバム (おそらく名前) を曲のテーブルに入れることに関しては、アルバムに関する他の情報がなければ、それ自体のテーブルではばかげているように見えます。ただし、名前以外のアルバム固有の情報がある場合 (たとえば、アルバムのリリース日は個々の曲のリリース日と異なる場合があります。また、曲は複数のアルバムに表示される場合もあります)、困っている。

于 2012-04-23T16:14:04.310 に答える
1

1 つの曲に複数のアーティストを含める場合は、アーティストと曲の間に、曲とアーティスト ID を含む別のテーブルが必要です。

タイトルの名前を編集するのは非常に簡単で、1 か所で行うことができるため、実際に保存するものがない場合も、アルバム用に独自のテーブルを作成することをお勧めします。そして、アルバムに画像を保存するのも面白いだろうと想像できます ;)

さらに、ユーザー名は一意ですが、常に整数を主キーとして使用するのが通常です。

于 2012-04-23T16:17:07.753 に答える