C# 数据库规范化和重复值

考虑数据库表模式中的父/子/孙结构，甚至更深层的层次结构。这些都是同一个集合。“一个表天”每天保留一行，并有一个“日期”字段。这是根表，也可能是根表的子表。无法删除此表中的任何行

在本例中，无论我的表模式看起来多么复杂，无论其他任何表在层次结构中的位置多么遥远，是否有任何其他表保留日期值的原因？它不能只在DAYS表中添加一个FK。

显然，我假设这些日期字段的创建不是在DAYS表中存在这样的日期字段之前发生的

---

我现在考虑的只是日期部分，而不是时间部分。不确定是否所有数据库都可以单独存储这些。这可能是相关的，但不是问题的主要焦点

如果使用外键，则必须在另一个表中查找实际值。

---

您可能会考虑节省空间，但外键仍然只有几个字节，而且您需要在days表上建立一个索引以加快查找速度

是的，您的表可以引用days表，但我不会询问只存储Date值的原因。我想问一下引入这种新关系的原因，它会减慢数据库的运行速度，并且至少根据您的描述，它没有任何附加价值。考虑引入一个包含所有可能整数的表，并从所有其他表中引用该表。这是可能的，但意义不大。您的示例与此非常接近。

您试图建模的业务流程是什么？为什么要以这种方式存储数据

看一看

我想知道对数据表示的关注是否凌驾于对数据库中实际需要存储的内容的需求之上

不要试图不必要地为时间建立一个模型。同样，这将取决于您试图建模的业务流程以及您希望实现的数据库解决方案OLTP/OLAP的类型

对于OLTP解决方案，您通常希望记录事件实际发生的特定时间（例如datetime数据类型），而不是对所有可能的时间值进行建模并试图将相关时间与事件关联起来。然后，您可以专注于报告或演示需求

---

对于OLAP解决方案，创建日期/日历维度以建模时间以支持数据分析和报告需求非常常见。

这通常在非关系维度建模的数据仓库中完成-日期维度表提供了许多功能，允许您通过date维度中存储的其他列，如year、quarter等。它通常包含几十列，这意味着您无需应用代码来确定这是工作日还是假日或周的日期名称或其他任何内容。这是一个经典的空间/时间权衡，对于几百年的有限日期范围内的数据来说，这是一个很好的回报，就像你在银行或企业中看到的那样。对于几百年的任意日期范围来说，这是不可行的

请注意，某些RDBMS系统具有更高效的仅日期数据类型（SQL Server在SQL Server 2008中有一种）。类似地，date维度中的PK通常是YYYYMMDD的自然形式的整数，这比常规datetime列占用的空间要小得多

这样的计划可能有好处。您可以使用非常特定的语义为某些日期保留特殊的维度--1-未知，-2-无效，-3-等待等，而常规日期列只能存储有效日期或NULL

出于性能原因，我认为连接不一定是反对这一点的论据，毕竟，您可能会对此进行非常有效的索引，这将导致索引查找。另一方面，典型的日期维度表有许多列，在OLTP场景中，您很少需要这些列

<>如果您的应用程序进行重数据分析和报告，我会考虑日期维度（或者称之为查找表，因为您可能不在维度/数据仓库方案中）。否则，我不会——大多数人对此不满意，而且在许多（大多数？）OLTP从业者中，接触尺寸建模技术并不常见，他们也不会看到好处，尽管显然有很多好处

我在您对另一个问题的答复中看到，您需要以分钟为单位记录数据。通常，正交时间维度是以类似的方式设置的。它通常也非常有效，具有HHMMSS或HHMM形式的自然密钥。这使得跨天数和时间表执行范围分析变得更加容易，特别是在可能需要使用附加属性标识这些桶的情况下

---

同样，SQL Server 2008有一个单独的仅限时间的数据类型，因此在表中简单地拆分日期和时间可能就足够了。

我明白了。。也许我概括得太多了。我正在开发的程序处理一天中连续记录的数据，并且我总是请求从第x天开始获取“这个和那个”。或者从第x天到第y天。所以我不仅仅是在考虑存储，而是认为基于这样一个引用进行查找也会更快。但如果这不是一个很好的理由，那么我似乎需要在所有表中引入一个日期字段。这似乎有点奇怪，但也许不是。你正试图接管数据库的工作。在日期字段上使用索引，您将获得希望通过日期表实现的目标。一种可能的优化方法是将完整日期转换为表示一天的整数（例如，自1900年1月1日起）。但是首先看一下您的DB文档。可能已经有了