重命名列还是追加列?这就是问题所在

我认为最安全的方法是创建一个 新表 创造 新存储过程和方法 .

但最好能理解整个系统…穿上这样的绷带会随着时间的推移变得一团糟。

创建新的表、存储过程和方法比向现有表添加/修改内容更为混乱。

编辑:我在一些有同样问题的网络应用上工作过。在我之前的多个开发人员以他们自己的风格添加和修改了一堆东西。我想你的情况差不多。

就像我说的。最好的方法是了解并修改整个系统。但是如果你不能,我发现最好是添加新的模块,而不是修改现有的模块。如果出了问题,很容易拔掉插头。另外,至少现在你已经知道了你的模块是如何工作的了。

如果现有的应用程序写得很好并且易于扩展,我想您不会在这里问这个问题。

所以…我最后的想法。

• 最佳:重命名列并相应地修改(如果您确切知道系统的工作方式)
• 安全:添加新列
• 最安全:为新列添加新表并创建新方法(重写或重载)

如果你 真的? 必须这样做, 当然可以选择第二种 .

我想是为了记录 对您不理解的数据库进行结构更改是导致灾难的一个秘诀。 祝你好运!

在源代码中搜索要重命名的列的引用。
我假设所有源代码都在某个源代码库中。(包括SQL脚本)。

如果找到了,您需要更改它们,并测试该功能。

此外,在进行这些更改之后,我将在测试环境中为与此相关的功能提供一个合理的测试。

如果你不这样做,你真的应该选择第二个选项。

理想解决方案:了解剩下的90%的系统:)

我将添加两个新列,并保留原来拼错的列。即使新的逻辑使用新的(固定的)列,旧的报告呢?旧逻辑?旧的插入/更新语句?

如果您不理解数据库模式,请不要重命名。谁知道你会破坏什么:)

一个(有点疯狂)选项是添加基本上只是重命名的列,将当前数据复制到它上面,然后重新设计原始列,使其成为返回新列值的计算字段。

这样就得到了重命名,但不会删除旧列。

更安全的办法是扭转局面。使新列成为一个计算值,该值只读取旧列并用它完成:)

或者,您可以创建一个视图,该视图将执行几乎相同的操作。

你知道,我在一个系统上工作,我们把旧的放在适当的位置,然后添加新的,然后继续使用。从长远来看,这造成了一个比改变原有结构更大的混乱。所以现在他们有了一个系统,他们根本不能标准化任何新的东西,因为有四种不同的结构来存储演讲者信息,两种不同的结构来存储代表信息,等等。所以每一个微小的变化都必须由客户定制,使得未来的维护工作更加困难。这既不高效,也不有效,而且维护成本更高。咬住子弹,找出什么会受到影响,然后立即改变一切。

Here's Scott Ambler在重构数据库方面做了一个很好的演示,他是一个真正的作家 the book 在重构数据库时。