考虑数据库表模式中的Parent / Child / GrandChild结构，甚至是更深层次结构。这些是相同的聚合。一个表DAYS每天保留一行，并且具有“日期”字段。这是根表，或者可能是根的子表。此表中不能删除任何行。
在这种情况下，无论我的表架构看起来多么复杂，但是在任何其他表的层次结构中都很远，是否有任何理由说明为什么任何其他表都会保存Date值？不能只是在DAYS表上有一个FK。
我显然假设这些日期字段的创建不是在DAYS表中存在这样的日期字段之前发生的。
我现在正在考虑相关的日期部分，而不是时间部分。不确定所有数据库是否都可以单独存储它们。这可能是相关的，但并不是问题的主要焦点。
答案 0 :(得分：1)
是的，您的表可以引用DAYS表，但我不会要求存储Date值的原因。我会问一个理由来介绍这种新的关系，它会减慢你的数据库速度，并且 - 至少根据你的描述 - 没有额外的价值。考虑引入一个包含所有可能整数的表，并从所有其他表中引用该表。这是可能的，但没有多大意义。你的例子非常接近。
答案 1 :(得分：1)
您尝试建模的业务流程是什么？为什么要以这种方式存储数据？
看看Designing Historical Tables。
我想知道数据展示的关注是否会覆盖您实际需要存储在数据库中的要求。
不要尝试不必要地为时间创建模型。同样，这将取决于您尝试建模的业务流程以及您要实现的数据库解决方案OLTP / OLAP的类型。
对于OLTP解决方案，您通常会查看事件实际发生的特定时间（例如日期时间数据类型），而不是对所有可能的时间值进行建模并寻求将相关时间与事件相关联。然后，您可以专注于报告或演示需求。
对于OLAP解决方案，创建日期/日历维度以模拟时间以支持数据分析和报告要求是非常常见的。
答案 2 :(得分：1)
这通常在非关系维度建模的数据仓库中完成 - 日期维度表提供了许多功能，使您可以通过存储在日期维度中的其他列（如年，季度等）轻松快速汇总事实。它通常包含数十列，这意味着您无需应用代码来确定它是工作日或假日，还是本周的名称或其他任何内容。这是一个经典的空间/时间权衡，对于数百年有限日期范围内的数据，您可能会在银行或企业中看到这些数据。对于数百年的任意日期范围来说，这是不可行的。
请注意，某些RDBMS系统具有更高效的仅限日期的数据类型（SQL Server在SQL Server 2008中有一个）。类似地，日期维度中的PK通常是YYYYMMDD自然形式的整数，它占用的空间比常规日期时间列少得多。
这种方案可能有优势。对于某些具有非常特定语义的日期，您可以拥有特殊的保留维度 - -1 - 未知，-2 - 无效，-3 - 等待等等，而常规日期列只能存储有效日期或NULL。
我认为加入不一定是出于性能原因而反对这一点的论据，毕竟，你可能会对此有一个非常有效的索引，并且它将导致索引搜索。另一方面，典型的日期维度表有很多列，而在OLTP场景中，您很少需要这些列。
如果您的应用程序进行大量日期分析和报告，我会考虑日期维度（或称之为查找表，因为您可能不在维度/数据仓库方案中）。否则，我不会 - 大多数人都不会对此感到满意，并且接触维度建模技术在许多（大多数？）OLTP从业者中并不常见，并且他们不会看到好处，尽管显然有很多。
我在您回复另一个问题时看到，您需要在一分钟内记录数据。通常，以类似的方式建立正交时间维度。它通常也非常有效，具有HHMMSS形式的自然键或仅HHMM。这样可以更加轻松地跨天进行范围分析，并使用时间表，尤其是存储桶，特别是在需要使用其他属性识别此类存储桶的情况下。
同样，SQL Server 2008有一个单独的仅限时间数据类型，因此只需在表中分割DATE和TIME就足够了。
答案 3 :(得分：0)
如果使用外键，则必须在另一个表中查找实际值。 您可能会担心保存空间但外键仍然是几个字节加上您需要在days表上使用索引来更快地查找