在我正在处理的项目中，我们有一个事件表，每个事件都可以链接到大约 20 个不同的“事件详细信息”表中的一个...
例如如果事件是“工作”类型，那么它将有相应的 activity_details_work 记录，如果它是“病假”类型，那么它将有相应的 activity_details_sickleave> 记录等等。
目前我们正在加载事件，然后对于每个事件，我们都有一个单独的查询以从相关表中获取事件详细信息。如果您有数千个事件，这显然不能很好地扩展。
所以我最初的想法是使用一个查询来一次获取事件并加入详细信息，例如
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 多个字段，其中大部分是空的，感觉很糟糕。
延迟加载细节也不是真正的选择，因为核心逻辑中几乎总是需要细节，至少对于主要类型而言是这样。
有没有我没有想到的 super 聪明的方法？
提前致谢
最佳答案
我的建议是为每个 ActivityType 定义一个专门针对该事件定制的 View 。
然后在ActivityType 字段引导的Activity 表上添加一个索引。 Cluster 表示索引，除非迫切需要对其他一些进行集群(或者性能基准测试显示其他一些集群选择的性能更高)。
设计这种非规范化程度是否有特殊原因？这个原因众所周知吗？
关于mysql - 使用大量可能的连接进行查询的最佳方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16252444/