一个巨大的收藏表，或单独的表，例如：MusicPlaylist，VideoPlaylist

Question

我正在构建一个大型社交网站的数据库结构。网站中有很多不同的资源类型：

1. 音乐
2. 视频
3. 帖子
4. 照片
5. 插图

人们可以使用播放列表（用于音乐和视频），相册（用于照片）来组织他们...等等。

但是在播放列表和专辑的深处，几乎是同一主意：

  

它只是一个收藏。

所以基本上我有两种设计表的方式。

---

解决方案A

每个资源都有自己的 collection 表。

• MusicPlaylists
• VideoPlaylists
• PhotoAlbums
• IllustrationLists
• Favorites

TABLE: MusicPlaylists, VideoPlaylists
+----+-----------+-----------+----------+
| ID |   Name    | CreatorID | Playtime |
+----+-----------+-----------+----------+
|  0 | Dub-steps |       385 |      682 |
|  2 | asdasdasd |       972 |       60 |
|  3 | for party |       484 |    92841 |
+----+-----------+-----------+----------+

TABLE: PhotoAlbums
+----+-----------+-----------+
| ID |   Name    | CreatorID |
+----+-----------+-----------+
|  0 | Earth     |       741 |
|  1 | my family |       194 |
|  2 | hello, wo |       513 |
+----+-----------+-----------+

IllustrationLists, Favorites...so on.

解决方案B

所有资源类型的巨型Collections表。

TABLE: Collections
+----+--------------+-----------+--------+
| ID |     Name     | CreatorID | TypeID |
+----+--------------+-----------+--------+
|  0 | my music     |       385 |      1 |
|  1 | earch pics   |      7314 |      2 |
|  2 | anime videos |       972 |      0 |
+----+--------------+-----------+--------+

TABLE: CollectionTypes
+----+-------+
| ID | Name  |
+----+-------+
|  0 | Video |
|  1 | Music |
|  2 | Photo |
+----+-------+

使用此解决方案，它需要一个额外的CollectionMetadata表来存储不同集合类型的元数据。

TABLE: CollectionMetadata
+--------------+------------+-------+
| CollectionID | MetadataID | Value |
+--------------+------------+-------+
|            0 |          0 |   325 |
|            2 |          0 |   523 |
+--------------+------------+-------+

TABLE: MetadataTypes
+----+----------+
| ID |   Name   |
+----+----------+
|  0 | Playtime |
+----+----------+

问题

哪种解决方案适合大型社交网站和更面向未来或更具有优势？