歌词网站的数据库设计

5

我对PHP和MySQL还不熟悉。我的项目是一个歌词网站。如何设计数据库和关系?

以下是我目前的设计:

艺术家

  • 艺术家ID
  • 艺术家姓名
  • 艺术家简介
  • 艺术家头像

专辑

  • 专辑ID
  • 艺术家ID
  • 流派ID
  • 专辑名称
  • 发行年份

流派

  • 流派ID
  • 流派名称

曲目

  • 曲目ID
  • 曲目名称
  • 专辑ID

如果有错误,请告诉我。


看起来不错。除了“genre”应该拼写为“genre”,而不是“genere”。 - j_random_hacker
14
除了你将“genre”拼写成“genere”,并且似乎没有地方存储音轨歌词,后者对于一个歌词网站来说似乎是一个相当基本的缺陷之外,其他都没问题。 - Dominic Rodger
实际上,这是个很好的观点,Dominic! :) - j_random_hacker
3
我并不是要打击你,但是已经有足够多的歌词网站了吧?http://www.google.com/search?q=lyrics - Sasha Chedygov
1
我曾经看到RIAA正在打击歌词网站,甚至是吉他谱网站。如果你计划将这个东西发布到全世界,请先查一下是否会受到他们的麻烦。 - Scott Evernden
1
抱歉打错字了。虽然路上已经有很多车了,但这并不意味着汽车制造商会停止生产汽车。至于RIAA,我是为我的学校项目而制作它,并非为了赚钱 :) - sunidhi
6个回答

14
  1. 在表名是单数还是复数方面保持一致。我更喜欢使用单数形式,因为这样,在执行多表查询时,可以简单地引用列名 "track.id",而不是 "tracks.id"。

  2. 确保所有的表和字段名称都拼写正确(例如 "genre");这是以后难以更改的事情。

  3. 最后,我不建议在列名前加上父表的名称。这只是多余的。


艺术家

  • id
  • name
  • bio
  • thumb

专辑

  • id
  • artist_id
  • genre_id
  • title
  • release_year

流派

  • id
  • name

音轨

  • id
  • title
  • album_id

我正在撰写类似的回复;这位先生是正确的。 - Dean Rather
5
最后但同样重要的一点:要有一个放置实际歌词的地方! - Sasha Chedygov
1
+1 单数/复数表命名的问题很棘手 - 是的,你可以使用 track.id,但是你也需要使用 select * from track,在我看来,这种写法不如 select * from tracks 自然。 - Dominic Rodger
没错,我会处理单数/复数。 - sunidhi

7
我强烈推荐使用WWWSQLDesigner来设计你的数据库。brianreavis提到的指导方针真的值得听取。始终使用正确的拼写、一致的语法、大写和下划线(_)。此外,您可以考虑使用关系表添加多个类型。
  album_genre ( id int, album int, genre int )

对于专辑或艺术家图片,我建议您将它们保存到一个带有相关id的文件夹中。请注意,

 id = 14
 artist = 42
 title = Mask And Mirror
 year = 1994

 thumbnail: /thumbnails/album-14.jpg

我可能再加一个关于WWWSQLDesigner的,它还可以从您的设计中生成表创建查询。这是一个非常方便的工具。您只需几分钟就可以为您的网站设置它。 - Cem Kalyoncu
感谢WWWSQLDesigner,它使生活更轻松。 - sunidhi

7

你的设计看起来相当不错。以下是一些你可能想要添加的额外表格:

  • 播放列表
  • 播放列表曲目
  • 已播放曲目

你可以向曲目表格添加其他字段。例如:

  • 曲目排序
  • 曲目年份
  • 曲目流派
  • 曲目长度
  • 用户评分
  • 比特率
  • 作者
  • 版权
  • 播放次数
  • 上次播放日期
  • 添加日期

trackSortOrdertrack 表中的作用是什么? - Dominic Rodger
1
trackSortOrder将用于指定单个专辑中曲目的顺序。 - Brian
什么是作者的用途,既然我们已经添加了艺术家? Trackyear已经在专辑发行年份中添加了。 - sunidhi
1
我在考虑有些歌曲是作为单曲(即混音版)发行的,因此它们不一定与某个专辑相关联。您无需创建专辑条目即可将曲目保存到数据库中。当我说作者时,我的意思是歌曲的创作人(并非总是演唱者)。 - Brian

3

在设计过程中应该要问自己的重要问题:

  • 我的需求是什么?对于你的情况,你的歌词网站需要包含哪些信息?它应该告诉我谁写了这首歌?它是在何时写的?谁都唱过这首歌等等。所以首先你必须定义范围!你的实体和数据库设计将取决于此。
  • 我的实体是什么?
  • 我的主要实体之间的关系是什么?

你的设计可能非常好,并且可能完美地适合你的需求,但根据你处理的复杂程度(需求范围!),你可能需要注意以下事项:

  • 艺术家和专辑实际上有多对多的关系。许多艺术家可能参与同一张专辑的制作,当然一个单独的艺术家会有多个专辑。你当前的设计可以解决这个问题,但是当多个艺术家一起工作时,你是否想要重复 genreId、title、release_year 这些值?这里存在一个折衷,可以创建更多的表并存储重复的值。你当前的设计可能非常适合你正在做的事情,但只是想确保你已经考虑过这个问题。
  • 在现实世界中,多个艺术家合作创作歌曲。大多数歌曲都是由别人写的,由其他人唱的。你需要定义“艺术家”对你来说意味着什么。是唱这首歌的人吗?还是写这首歌的人?两者都是吗?如果我搜索一位没有唱过任何歌的歌曲作者,它是否会返回结果?
  • 我没有看到你存储歌词的表!但我猜你已经知道了 :)

我可以看到还有一些可能会在以后给你带来麻烦的事情,但正如我所说,我不知道你的需求范围! :)


这是我现在所做的:我添加了一个名为Artist_type的字段,以了解它是歌手还是作家。现在我不知道如何解决多个艺术家的问题。例如,一首歌曲由多位歌手演唱或由两位或更多的作家创作。 - sunidhi
1
如果艺术家既是歌手又是作曲家怎么办? :) 如果你开始设计然后再考虑需求,你会遇到很多问题。我建议你先定义你的需求范围,比如你的网站将提供哪些信息等等。一旦你做到了这一点,设计就会变得更容易。目前你正在试图击中一个移动的目标。 - Tequila Guy
我能把歌曲的作者存储在另一张表中吗?如果歌曲有不同的作者,则在作者表中创建一条记录,否则将使用艺术家的相同名称...因为如果我不这样做,那么对我来说会很混乱。 - sunidhi

0

您在几个地方混淆了多种不同类型的对象--例如,看起来您正在尝试创建一个适用于专辑、艺术家和曲目的单个rating表。请仔细考虑是否更容易为这三种不同类型的评级分别建立三个单独的表。

对于comment也是同样的情况。此外,在该表上,您当前的结构(在专辑、艺术家或曲目上有一个单一的comment_id)似乎会限制每种类型的对象只能有一个评论,这是没有意义的。

对于genretypethumb,请考虑将这些表内联到父对象中。例如,是否有可能存在一个单个的缩略图行被多个艺术家共享,或者直接将每个艺术家的thumb路径存储在其中是否更容易?

最后,对于您绘制的所有关系,您需要定义关系的基数。对于每个关系,定义哪个表引用另一个表,并且在另一个表中每行可以存在多少行。例如,albumtrack之间的关系是一对多关系,因为每个专辑包含多个曲目,但每个曲目属于一个专辑。使用诸如“crow's foot notation”之类的符号表示此信息。


-3

对于专辑,是否考虑单独建立一张表,并且再建立一张公共表来定义所有其他表之间的关系呢?


单独的关系表?不好意思,我能问一下为什么吗? - Dominic Rodger
更多的外键引用可能会导致问题...我认为这可以简化数据库模式。 - Gopi
1
较少的关系表使得外键约束不可能,这会导致更多问题,这一点我原本认为只会带来更多问题。单个关系表如何设置?使用“relationships”及“column1”和“column2”吗?连接操作有多清晰易读?相比减少表数量,我更愿意为每种类型的关系创建一个表,虽然这会使数据库模式包括更多部分,但这将使其更简单明了。 - Dominic Rodger

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接