我将评论我目前在设计数据库时遇到的情况。
我有以下表格：
user (id, name, lastname)
role (id, name)
user_role (user_id, role_id, from_date, to_date)
period (id, name, from_date, to_date)
周期表充当数据主控，以了解我在应用程序中定义的周期名称。
在这种情况下，我只提到user,role和user_role表，但还有更多带有句点的表。
周期表的目的是充当模型表中存在的不同时期的标签系统。该表与其他表没有任何外键关联。为了进行搜索并将其他表与此相关联，使用日期 from 和 dates to 进行连接。
例如，user_role表的元组可以具有涵盖周期表中定义的多个周期的起始日期和截止日期，因此将使用它所包含的周期名称进行标记。
period表可以是不相关的表吗？它只是用来给句号命名，这就是我这样说的原因。你能想出另一种更好的方法来提高它吗？周期表是否应该以其他方式与其他表相关？
提前致谢。
感谢您对我的查询的答复。
我对此的看法：
将一个表链接到其他表需要某种在这种情况下不可用的一致性。看到这些输入，恕我直言，我们可以安全地将这个表保存为单独的实体。
从性能方面来看，我们可以根据应用程序对周期表的需求来制作更好的索引，以避免任何瓶颈。
谢谢，
桑吉瓦
您应该区分逻辑数据模型和物理数据模型。逻辑模型记录了用户如何看待他们世界中的对象和概念，以及这些事物如何相互作用。物理模型说明了您作为程序员如何在性能良好的软件中实现这些业务实体。
对于您系统的用户，user_role 实体类型涵盖多个时期，这些时期的名称保存在称为“时期”的实体类型中。在逻辑级别，这两种实体类型之间存在关系，因为一种拥有另一种的名称。用户希望引用 period 实体以完成 user_role 实体中保存的信息。
当您在特定 DBMS 中实现该逻辑模型时，您可能会将每个实体类型实现为一个表。同样，您可以选择将逻辑关系声明为物理外键约束，并让 DBMS 软件为您强制执行。或者你可以选择不这样做。
有充分的理由声明外键，也有充分的理由不声明. 没有什么说您必须在数据库设计中使用它。但是，如果您选择不这样做，则必须找到另一种方法来完成外键所做的工作（确保数据完整性），或者接受不做该工作的风险。如果您确实实施它，您必须接受在设计时（期间 - user_role 可能是多对多，因此需要进一步的交集表）和运行时（验证外键约束）所需的额外工作。
作为一个具体的例子，我在许多系统上工作过，每个表中都包含 created_by_user 和 modified_by_user 。我不会将这些声明为用户表的外键，因为它们不支持业务数据的完整性——它们充其量是程序员的方便调试辅助工具。这些系统确实有 invoice.written_of_by_user 和 grant.approved_by_user 等列。这些列对于保存它们的系统的目的至关重要。在其中拥有良好的数据至关重要，并且将这些数据的完整性保持七年是一项法律要求。对于这样的列，我会声明外键。
对于所有系统，没有一个答案是正确的。权衡成本和收益，与用户和项目发起人讨论，并准备好在出现新考虑时更改您的实施。