（建议将其从StackOverflow重新发布在此处）
当前有一个表..，需要开始向其中添加新的数据列。并非每条记录（甚至在添加新数据列之后使用新数据）都将具有数据。所以我想知道这是否更适合新表，因为它实际上是某些数据行的扩展，并且不适用于每一行。
换句话说，由于这些新数据元素将有许多未使用的列，因此，这似乎更适合于新表？
第一个表是页面浏览量的记录（当前有200万条记录）
- ID - IP地址 -浏览次数 -时间戳创建时间 -日期
对于每个IP地址，每天进行一次记录-并将连续的网页浏览量添加到每天的浏览量中
其他字段将用于原点跟踪（即Google Analytics（分析）来源/媒介/广告系列）
并非每次访问都会获得该信息。我会假设大约10％的行将包含数据（因为通常仅在首次访问时才归因于该数据）
数据的主要用途是归因于人来自何处。这可能会被更频繁地使用（然后似乎使自己适合单个表）
欣赏反馈-如果需要，可以添加更多
Answers:
您正在努力的是垂直分区。这是一种提高性能的物理数据库设计技术。与任何物理数据库设计技术一样，其适用性取决于您要优化的特定查询以及该技术是否可以优化它们。从逻辑的角度来看，如果这些新字段取决于您实体的候选键，那么它们就是与之相关的事实。首先，您应该确保您完全了解这些新字段对候选键的功能依赖性，以验证它们确实是有关每日页面浏览量的事实。如果是这样，则决定将它们分区到另一个表中是一项性能优化，只有在达到您的性能目标时才应该执行。
通常，如果您不经常且与原始表中的其他列不同的是查询这些新列，则垂直分区很有用。通过将这些列放在与现有表共享相同PK的另一个表中，可以在需要这些新列时直接查询它，并获得更大的吞吐量，因为此新表在磁盘上每页将有更多行因为原始表中的所有列都不会位于这些行上。但是，如果您总是将这些列与原始表中的列一起查询，那么垂直分区就没有多大意义，因为您将始终必须进行外部联接才能获取它们。磁盘上的表中的页面独立进入DBMS的缓冲池，永远不会预先加入，这样，即使数据固定在缓冲池中，每次查询执行都必须进行联接。在这种情况下，将它们设置为原始表上的NULLABLE列将使DBMS存储引擎可以在NULL时有效地存储它们，并且无需进行检索。
在我看来，您的用例是后者，然后将它们作为NULLABLE添加到原始表中是可行的方法。但是，与数据库设计中的所有其他内容一样，它取决于并且为了做出正确的决定，您需要知道预期的工作量以及做出好的选择取决于什么。垂直分区的正确用例的一个很好的例子是人员搜索面板，该应用程序的应用程序中包含一些关于人员的极少数填充信息，而有人可能想要搜索但很少有人搜索。如果将这些信息放在另一个表中，则可以选择一些不错的性能选项。您可以编写搜索，以便有2个查询-一个仅使用主要的，始终填充的信息进行搜索（例如姓氏或ssn），只有当请求搜索时，外部的信息才会加入到很少使用的信息中。或者，如果DBMS优化器足够聪明，可以识别给定的一组主机变量不需要外部联接并且不会执行外部联接，则可以利用DBMS优化器，因此您只需创建1个查询即可。
您正在使用什么DBMS平台？平台处理NULL列存储，优化查询的方式以及稀疏列支持的可用性（SQL Server具有此功能）都会影响决策。最终，我建议在具有生产规模的数据和工作负载的测试环境中尝试两种设计，并查看哪种设计可以更好地实现您的性能目标。
我个人倾向于将列添加到现有表中。新桌子并没有真正为您买任何东西：
where newcolumn is not null成为left outer join在单个表中，这仅意味着行的大小可以随页面的不同而变化-但这不会影响许多现有页面，尤其是当聚集索引位于单调递增的列（标识或日期/时间）上时。
给定您提供的信息，并且仅以一般归一化为目标，我可能会简单地添加可为空的列，但是您没有提供足够的信息以了解如何使用数据来了解最佳的数据建模方法是。
根据您实际使用这些数据的方式，您可能需要考虑其他数据模型。如果要将这些数据用于报告，则可能需要研究一个维度模型，该模型对于某些类型的报告可能会更有效-例如，按日期和时间维度划分出来的每日时间分析效果很好。
对于回答分析性问题，例如“在X等广告系列中，哪一天是访问者最常访问的时间”或“每小时看到最多访问次数是在广告系列中的哪一天”，因此一个数据时间列将无法正常工作很好（但是甚至可以在关系模型中进行拆分），并且在很多情况下，您可能会将IP地址视为维度（也许在雪花中包含某种地理数据）。