我的表中字段太多,但要添加更多字段

IMO 130油田 方式 太多了。这听起来确实像一个设计糟糕的数据库(或者一个懒惰的开发人员:o))。

如果你以后要清理这个烂摊子,我个人会添加这些字段。但只有当我知道我有时间尽快修复它。添加一个扩展表听起来像是另一个修补程序,并且在3-4年内开始修复另一个问题。

您可能希望稍后添加一个设置表-或类似的内容。或者稍后将这些字段移到它们自己的表中,按它们的函数分组。

现在修复它…

130对很多人来说是,如果你让它滑了,那么你以后就没有时间来修理它了(除非它坏了)。

现在你有了一个“借口”,可以在这里进行真正的修复了。不要创建一个扩展表,而是尝试获得“批准”以按比例拆分表,因为“SQL Server中的数据行只能容纳8KB”

如果你以后一定会回来修好它,那就没问题了。你得暂时别挡道,对吧?

黑客在扩展表,做一个记录,并回来妥善修复它时,你有时间。

130个领域是一项成就。当你达到200时在这里写一篇文章。

我可以建议(但不会坚持)把桌子分成几张小一点的。按字段的统一使用分组。如果表的某些部分处理设置,请将其设置为设置表。

另一种选择是按使用频率对字段分组。为最常访问的字段创建一个小表,不常用的字段可以转移到另一个表中。因此,您将改进性能指标。

现在可以拆分表并创建与旧表同名的_view,从而替换它。添加新字段是一个难题。在使用_view时,您可能希望创建索引视图以提高性能,但它会增加对存储的需求。

稍后,当您有时间时,请执行重构。

如果该表已经非规范化,即并非所有130个字段都由主键标识,那么向该表添加一个新字段将不会引入您还没有的任何新问题。

实际上,我建议您这样做,而不是添加一个可能与主表有有效关系或可能与主表没有有效关系的全新表。

在添加任何新表之前,我将尝试通过将表转换为第三种正常形式来认真地整理设计。因此,在现在完成某项工作,然后在以后进行适当的重构之间,添加额外的字段是一个合理的折衷方案。

现在修复它的建议很诱人,但可能放错了地方。向现有表中添加列是半天的工作。而将表拆分成几个较小的表、构建视图、迁移数据、回归测试…这是一项大而有风险的工作,这就是为什么你以前没有解决它。

将最新的更改作为一个单独的表应用会给系统增加额外的复杂性,而不会带来任何好处,除了作为意向声明。而且,让我们面对它,直到表的宽度成为性能问题或以其他一些可测量的方式影响应用程序,解决它仍然是项目任务列表的底部。

所以,要实事求是:将列添加到现有表中。这让人恼火,但替代方案更糟。