DBA如何处理这个问题？我已经取得了1999年编写的现有应用程序（VB6）和数据库的所有权。数据库设计相当“平坦”，这意味着主要表格相当宽（100多列），开发人员继续使用其他列到表的结尾。这导致列具有大量Null，因为它们与主键没有直接关系。
我正在考虑将主表拆分为一种从“多年爆炸”多年来抽象自己的方法。我确信随着新要求的出现，新领域将继续增加。
所以问题是，由于需要新字段，您是否继续增加现有表的宽度？或者，您是否停止扩展现有表并将其拆分为一个单独的支持表，该表将容纳新字段，从而创建一对一关系？如果你要拆分主表，你的命名方案会是什么？
我们假设在这个例子中我有一个名为'Foreclosure'的表，有150个字段。 新的1对1桌子有什么好名字？ 'ForeclosureExtended'？ ForeclosureOtherInfo'？
顺便说一句，有些视图和存储过程需要修改才能支持任何新表，但是在添加列时无论如何都是不可避免的。
提前感谢任何想法。
答案 0 :(得分：1)
80％的时间，您的空值都有明确的模式。
这些模式定义了表的子类。在您的情况下，它们将是Foreclosure的子类。
你的分裂应该基于这些子类关系。
比如说，例如，一些Foreclosure个实例有一堆与法律诉讼相关的字段几乎全部被填充。而其他Foreclosure个实例的法律诉讼字段完全填充了空值。< / p>
你有两节课。你需要弄清楚它们之间的关系 - 它们是超类 - 子类还是它们是某些其他超类的对等子类？
这告诉你如何对表进行分区以使有用的东西发生。
您可能拥有适当的超类子类关系
您可能找到了一个事物（LegalProceeding），它应该一直是一个单独的表。它不应该永久地加入Foreclosure。这非常普遍。
您现在有一些关系实现选择。
一个常见的选择是将所有子类放入一个包含大量空值的单个大型表中。这就是你今天所拥有的，它不起作用。
一种选择是将两个子类关系表拆分为对等，复制公共信息。
一种选择是让超类表具有对子类中其他信息的可选FK引用。
一种选择是让子类表具有对超类信息的强制性FK引用。
答案 1 :(得分：1)
除非你真的很勇敢，否则应用程序非常小/简单，或者存在重大性能问题而无法修复架构。如果没有损坏，请不要修理它。
只需创建一个新表ForeclosureExtended，就像您建议使用相同的密钥并开始添加列一样。或者，当出现新列时，您可以使用分组列创建正确的表。无论哪种方式，如果架构这么糟糕，我敢打赌代码非常脆弱。
答案 2 :(得分：1)
为什么你觉得你有问题？在我看来，处理一个包含大量列的表比处理大量较窄的表以及您必须维护的所有相关视图更容易。