目前我正处于优化阶段。
我倾向于使用多个表，所以我没有空列。
我的问题是，空列是一个大问题吗？我不是在争论太空。我指的是索引速度，数据检索等......
我的赌注示例是当我有一个简单的客户表时，有些列并不总是填充。像电子邮件，dob，ssn或pic。我会说大多数时候他们都没有填写。
这使我创建一个新表来容纳辅助数据。 但如果我将这些列与其他客户信息放在同一个表中，它真的会有所作为吗？
如果我这样做，那么会有很多空列的记录。这让我想知道当记录数量巨大时，这会对性能产生多大影响。
答案 0 :(得分：1)
如果将它们存储为可变长度字段（例如：VARCHAR），则空列不会占用（任何？）空间。与仅具有固定长度字段的表相比，这是以较慢的查找为代价的。
我个人认为拥有空列很好，即使你有很多列（也称为稀疏表）。有些数据库甚至对稀疏表进行了优化。如果你开始有许多额外的表，你的逻辑会变得更加复杂，并且这使得维护参照完整性变得更加困难。
您在customers表中可以做的是与customer_profiles表格建立一个额外的customers表格，其中包含1：1的关系。在customers表格中将基本信息存储在customer_profiles和其他信息中（例如：每次您查找客户时不需要）。
答案 1 :(得分：1)
如果您正在进行优化，我的建议是： - ）
优化是应该针对性能问题而不是一时兴起的事情。如果没有性能问题，所有优化都是浪费精力。
在正确设计的模式中，空字段很少会对数据检索产生很大的影响，因为大多数查询应尽可能仅使用索引来决定要获取哪些行。一旦发现了行，那就是当你去表格获取实际数据时。
索引的速度不会因为列存储在另一个表中而改变。如果需要编制索引，则需要对其编制索引。
我更喜欢我的架构尽可能简单（虽然仍然主要遵循3NF），以避免不必要的连接。
答案 2 :(得分：1)
使用外部表来托管辅助数据是其中一个选项，就像可以为空的列一样。
它可以节省一些空间，但需要更多资源才能加入表格。
如果您的模型是稀疏矩阵（许多属性，其中大部分都不会被定义），那么存储和扫描这些属性的成本甚至可能超过JOIN的成本。
但是，使用附加表格，您将无法创建涵盖不同表格中两个属性的索引。
关系模型通常允许使用多个方法来实现ER模型，而这恰恰说明了它。
您可能想阅读这篇文章：