Database 我应该将可选记录属性放在单独的表中吗？

我有一张大约1000张唱片的表格。其中大约一半将使用一组包含某些特征的字段。大约有10个相关字段。另一半的记录不需要填写这些信息

此表是数据库的中心，将承担大部分操作。虽然只有大约1000张唱片，但数量不多

数据库所存储的硬件既旧又慢（旋转硬盘而不是SSD…），因此我希望有一个相当优化的结构来充分利用它。显然，由于空白字段而单独增加数据库的大小不是一个主要问题，但是如果它减慢查询，那就不好了。 我想我应该描述一下设置。当前访问2007客户端和访问后端，但后端将很快移动到SQL server。当前，后端位于主服务器机架上，但当移动到SQL server时，它将获得自己的旧服务器机架

---

因此，我应该创建一个单独的表来存储上述特征集，还是应该保持原样？

将可选字段放入单独的表中，然后使用联接的查询开销对大小或数据管理没有多大好处。特别是如果它是1对1的话，就像你的例子一样。对于大小，可选字段将为NULL，这对您影响不大。是的，75%是一个很好的随机阈值，用于确定何时应该开始移出内容，但即使如此，通过移出可选字段（如果它们与记录是1:1的，并且您总是将其与主记录一起取出），实际上也没有对任何内容进行规范化

值得注意的是：对于大多数DBs，在单个查询中获取大行比在几个小查询中获取大行要好……以防以后您迫切需要在单独的查询中获取第二个表中的可选数据。但在Access 2007中，这一点可能不那么重要

---

无论您是否将这些可选字段移出，都要为那些可以在

中使用的字段添加索引，其中
/
具有
/
连接
我的印象是您应该使用单独的表。您想要表示的依赖关系和数据完整性的需求（“业务规则”）应该决定任何属性进入哪个表

在你的情况下，听起来你有两种事实需要陈述。这些事实类型具有不同的属性集，因此它们属于不同的表。如果将两种不同的事实类型合并到一个表中，并使一组属性可为空，则可能会损害数据完整性：即，当业务规则不需要某个属性的值时，允许该属性的值；当业务规则实际需要某个属性的值时，允许该属性的值不存在

关于更正式的回答方法，请参见第五范式和正交设计原理。如果您还不了解这些设计原则，那么您应该熟悉它们。
对于大型数据集来说，垂直分区有助于提高缓存的效率。即使在相当旧的硬件上，1000行也不符合“大”的条件

因此，除非有其他原因重新设计此表（您不是这样做的吗？），否则就可以开始了。
好吧，将它们放在单独的表中会增加额外的开销，并且会使查询更加困难。。。。既然您说大约有一半的行有这些列，我可能会将它们放入主表中，并使它们可以为空。如果75%或更多的列是“可选的”（仅对给定的行集有效），我只会转到一个单独的表。只是一个粗略的“经验法则”是真的，增加的复杂性会有点烦人，尤其是对于表单之类的。“后端将很快移动到SQL server”那么现在有什么可以阻止您为SQL server构建它呢？安装SQL Server Express只需约10分钟。SQL Server的最佳实践应用程序设计与Jet/ACE非常不同。即使是唯一性约束和引用完整性等基本特性也会有不同的工作方式。我建议，如果从一开始就为SQL Server设计它，您可以节省大量的工作。我想首先更改字段和表名，因为在开始构建时，我没有遵循良好的命名实践（标准化、无空格等）。我想我也在考虑换桌子。原因是我对SQL Server几乎一无所知，我认为在过渡期间尽量减少我必须跨越的“学习障碍”是明智的。SQL server的转换将在下周或工作完成后的一周进行，不过我会尝试尽快开始处理它。为了澄清您的意思，OP没有指定事实类型，只是将其可选属性设置为可选。因此，错误实现的业务规则（在数据库或程序级别）将影响不可为null的值以及可为null的值；quote：“当业务规则不需要某个属性的值时，允许该属性的值；当业务规则实际需要某个属性的值时，允许该属性的值不存在。”那么，将其移动到单独的表中如何解决该问题呢？由于这些信息是同一条记录的1-1部分，imho，5NF不适用。Aneroid似乎非常了解我的情况。考虑业务规则是一个很好的观点，但是这里没有关于不包含数据的严格业务规则。数据可以完全正确地填充为空，但它不会那么有用。@andrewb，我无法确定数据中的依赖项，这就是为什么我开始说“根据您所说的”。但如果您确实需要关于属性归属的指导，那么依赖理论和规范化应该是您的指导。还要注意，“可选”属性所暗示的关系是1到0/1，而不是1到1。@s