下面是一个示例模式来说明我所说的内容：
假设我正在存储一些活动（研讨会、培训等）的信息，这些活动是在一组特定的地点举办的，按类型（黑客空间、游泳池等）和城市进行标识。每个活动一次发生在适当类型的所有位置（例如，任何编程研讨会一次发生在所有黑客空间），因此任何人都可以选择参加任何适当位置的活动。因此，任何活动都只与某个位置类型关联，而考勤记录与某个活动（因此隐式地与某个位置类型关联）和该特定用户参加活动的城市关联。
到目前为止，系统中最常见的查询是生成给定人员参与的所有活动的报告。
我是不是觉得这很难看？我应该重新设计这个，如果是，怎么做？
我不想透露我在一个数据库中存储的实际数据，在这个数据库中我不得不采用类似的设计，所以我希望这个类比有一定的意义。
最佳答案
听起来您需要一个包含位置类型列表的LocationTypes表。然后，Location可以与LocationTypes有外键关系。
但是，我不喜欢假设位置集不会随着时间而改变。所以这过于简单化了。所以，我会有另一个类似于LocationSets的实体，它会列出一段时间内给定活动的位置。LocationSets将包含可使用的“类型”。与位置集关联的位置将位于另一个表中，连接位置集和位置的连接表。
那么Activities将有一个LocationSetId。Attendance会有一个LocationId。您可能希望在任何给定的时间强制执行Attendance位置与Activity中的位置一致。这可以在应用程序层通过数据库中的触发器，或者通过诸如基于函数的约束（如果数据库支持这些约束）之类的机制来完成。
关于database - 如何摆脱“间接”外键？我是不是该？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/33189161/