使用表作为数组来实现一对多关系是否更好？

Question

最近在研究数据库设计，学习数据库中的关系。因此，例如，想象一个用于音乐管理的应用程序，基本上有专辑和曲目，每个专辑有很多曲目，但每个曲目有一张专辑。据我所知，应该这样做：

曲目：

id	姓名	album_id
1	测试 1	1
2	测试2	1
3	测试3	2
4	测试4	1
5	测试5	2

专辑：

id	姓名
1	专辑1
2	专辑2

这是一个基本的一对多关系。但是，如果我想获得专辑中所有曲目的列表，我应该运行对曲目 table 和 select 具有匹配 ID 的所有行进行查询，这也意味着处理 ID 不匹配的。相反，如果每张专辑在 table 中都有一个曲目数组作为一列呢？所以这无法完成，但我可以为每个名为“Album1_Tracks”的专辑创建一个 table 并在其中存储曲目并向专辑 table 添加一个名为“Table_Name”来识别查询时的table。该模型将如下所示：

Album1_Tracks:

id	姓名
1	测试 1
2	测试2
3	测试4

Album2_Tracks:

id	姓名
1	测试3
2	测试5

专辑：

id	姓名	Table_Name
1	专辑1	Album1_Tracks
2	专辑2	album2_Tracks

在这种情况下，每当我想获取专辑中所有曲目的列表时，我只需要通过查询获取 table 名称，然后获取该 table 中的所有记录没有检查任何东西。虽然在这种设计中查找特定曲目的专辑名称效率太低，但如果我只想获取专辑中所有曲目的列表而不是反之，这种设计在查询性能方面是否更好？

编辑：JOIN 通常用于此目的，但这种设计会比 JOIN 获得更好的性能吗？

Answer 1

一般来说，SQL 与少量 table 相比，对于特定实体的每个实例都需要一个新的 table 的设计，效果要好得多.

在您的情况下，相关实体是相册。根据您的第一个设计，将您所有的相册放在一个 table 中，并使用单独的 id 值。

形式的查询

SELECT Track.Name, Album.Name
  FROM Track
  JOIN Album ON Track.Album_ID = Album.ID
 WHERE Album.Name = 'Revolver'

效率惊人。它将利用 Album_ID 列上的 SQL 索引。如果索引存在，它将避免您在问题中提到的完整 table 扫描（“处理具有不匹配 ID 的”）。

第二种方法还有另一个问题：在 SQL 查询中，table 的名称必须是常量。您不能将列的值用作 table（或列或数据库）的名称。

程序员花费了数千（真的）年的时间来提高 SQL 查询的效率。试图超越 MySQL 或其他 RDBMS 软件中的查询优化器软件几乎没有任何收获。

使用表作为数组来实现一对多关系是否更好？

Is it better to implement one-to-many relationship using tables as arrays?

database-design

query-optimization

relational-database

relationship