4

在我正在进行的项目中，我们有一个活动表，每个活动都可以链接到大约 20 个不同的“活动详细信息”表中的一个......

例如，如果活动是“工作”类型，那么它将有一个相应的activity_details_工作记录，如果它是“病假”类型，那么它将有一个相应的activity_details_病假记录等等。

目前我们正在加载活动，然后对于每个活动，我们有一个单独的查询来从相关表中获取活动详细信息。如果您有数千个活动，这显然不能很好地扩展。

所以我最初的想法是有一个查询，它可以一次性获取活动并加入详细信息，例如

SELECT * FROM activity
LEFT JOIN activity_details_1_work ON ...
LEFT JOIN activity_details_2_sickleave ON ...
LEFT JOIN activity_details_3_travelwork ON ...
...etc...
LEFT JOIN activity_details_20_yearleave ON ...

但这将导致每条记录都有 100 个字段，其中大部分是空的，感觉很糟糕。

延迟加载细节也不是一个真正的选择，因为在核心逻辑中几乎总是要求细节，至少对于主要类型是这样。

有没有我没想到的超级聪明的方法？

提前致谢

4

3 回答 3

2

您的活动表很可能是类似的(date_from, date_to, with_who, descr)或类似的东西。正如 Pieter 建议的那样，考虑在其中折腾一个类型 varchar 或 enum 字段，以便处理单个详细信息表。

如果有合理的理由将表格分开，请考虑添加保持布尔/小整数字段（has_work、has_sickleave等）或位字符串（has_activites_of_type第一个位置等于has_work、下一个位置等）的触发器has_sickleave。

无论哪种方式，通过在一个或多个单独的查询中获取活动的详细信息可能会更好——如果只是为了避免字段名称冲突。

于 2013-04-27T14:08:46.893 回答
2

我的建议是为每个 ActivityType 定义一个视图，专门针对该活动定制。

然后在 Activity 表上添加一个索引，由 ActivityType 字段引导。集群表示索引，除非非常需要对其他一些集群进行集群（或者性能基准测试显示其他一些集群选择的性能更高）。

设计这种程度的非规范化是否有特殊原因？这个原因众所周知吗？

于 2013-04-27T13:48:58.537 回答
1

我不认为 enum 是要走的路，因为正如你所说的可能有 1000 的活动，那么改变你的activity表将成为一个问题。

对大量表进行左连接也没有意义。

所以你有的选择是：

  1. 看到这个第一条评论可能有用。

  2. 我猜您的活动表有一个名为activity_type_id. 构建一个名为activity_types包含字段activity_type_id, activity_name,的表activity_details_table_name。首先通过以下方式查询

    活动
    内部连接
    活动类型
    使用（活动类型ID）

此查询为您提供查询详细信息的表名。这样，您只需在 activity_types 表中添加一行即可添加任何新的活动类型。

于 2013-04-27T15:19:10.683 回答