(这被建议从 StackOverflow 转发到这里)
当前有一个表 .. 并且需要开始向其中添加新的数据列。并非每条记录(即使在添加新数据列后继续处理新数据)都会有数据。所以我想知道这是否更适合新表,因为它实际上是某些数据行的扩展,并不适用于每一行。
换句话说,由于这些新数据元素会有很多未使用的列,所以这似乎更适合新表?
第一个表是页面浏览量的记录(目前有200万条记录)
- ID - IP地址 - 查看次数 - created_at 时间戳 - 日期
对于每个 IP 地址,每天都会进行记录 - 并将连续的浏览量添加到每天的浏览次数中
附加字段将用于原点跟踪(即谷歌分析源/媒体/活动)
并非每次访问都会有这些信息。我会假设大约 10% 的行会有数据(因为它通常只归因于第一次访问)
数据的主要用途是确定人们来自哪里。这可能会被更频繁地使用(然后似乎适合单表)
感谢反馈 - 如果需要可以添加更多
Tod*_*ett 29
您正在处理的是垂直分区。这是一种提高性能的物理数据库设计技术。与任何物理数据库设计技术一样,其适用性取决于您尝试优化的特定查询以及该技术是否会优化它们。从逻辑的角度来看,如果这些新字段依赖于您的实体的候选键,那么它们就是属于它的关于它的事实。首先,您应该确保完全了解这些新字段对候选键的功能依赖性,以验证它们确实是有关每日页面浏览量的事实。如果是,决定将它们分区到另一个表是一种性能优化,只有在达到您的性能目标时才应该进行。
通常,如果您不经常查询这些新列并且与原始表中的其他列不同,则垂直分区很有用。通过将这些列放置在与现有表共享相同 PK 的另一个表中,您可以在需要这些新列时直接查询它,并获得更大的吞吐量,因为此新表的磁盘上每页将有更多行因为原始表中的所有列都不会位于这些行上。但是,如果您始终将这些列与原始表中的列一起查询,那么垂直分区就没有多大意义,因为您将始终需要外部联接才能获取它们。来自磁盘表的页面独立地进入 DBMS 的缓冲池,从不预先加入,因此,即使数据固定在缓冲池中,每次查询执行时也必须进行连接。在这种情况下,将它们设置为原始表上的 NULLABLE 列将使 DBMS 存储引擎能够在为 NULL 时有效地存储它们,并消除在检索时加入的需要。
在我看来,您的用例是后者,将它们作为 NULLABLE 添加到您的原始表中是要走的路。但与数据库设计中的其他所有事情一样,这取决于,为了做出正确的决定,您需要了解预期的工作量以及做出正确选择的依据是什么。垂直分区正确用例的一个很好的例子是人员搜索面板,其中您的应用程序有一些关于某人的很少填充的信息,有人可能想要搜索但很少这样做。如果您将该信息放入不同的表中,您将有一些不错的性能选择。您可以编写搜索,以便您有 2 个查询 - 一个使用主要的、始终填充的信息进行搜索(如姓氏或 ssn),并且只有在请求搜索时才加入很少填充的信息。或者您可以利用 DBMS 优化器,如果它足够聪明,可以识别一组给定的主机变量,不需要外部连接并且不会执行它,因此您只需要创建 1 个查询。
您使用的是什么 DBMS 平台?平台处理 NULL 列存储的方式、优化查询以及稀疏列支持的可用性(SQL Server 具有此功能)将影响决策。最终,我建议在具有生产规模数据和工作负载的测试环境中尝试这两种设计,看看哪种设计更能实现您的性能目标。
Aar*_*and 11
我个人倾向于在现有表中添加列。新表并没有真正给你买什么:
where newcolumn is not null变成left outer join在单个表中,这仅意味着您的行大小可能因页面而异 - 但这不应该影响您现有的许多页面,特别是如果您的聚集索引位于单调增加的列(标识或日期/时间)上。
| 归档时间: |
|
| 查看次数: |
18313 次 |
| 最近记录: |