重构过时的数据库模式的提示

每个开发人员的噩梦都是陷入不再反映数据模型的遗留数据库模式.然而,由于所有关于为可维护性重构代码的讨论,我都没有听说过重构过时的数据库模式.

有关如何在不破坏依赖旧代码的所有代码的情况下过渡到更好的架构的一些提示？我将提出一个具体的问题,我必须说明我的观点,但随意提供其他已证明有用的技术建议 - 这些技术也可能派上用场.

我的例子:

我的公司收到并运送产品.现在产品收据和产品装运有一些非常不同的数据,因此原始数据库设计者为收据和装运创建了一个单独的表.

在我使用这个系统的一年中,我已经意识到当前的架构并没有侥幸.毕竟,收据和货件基本上都是一个交易,它们各自涉及改变产品的数量,但只有+/-符号不同.实际上,我们经常需要找到产品在一段时间内发生变化的总量,这个问题对于这种设计来说是完全难以解决的.

显然,适当的设计是拥有一个Transactions表,其中Id是ReceiptInfo或ShipmentInfo表的外键.不幸的是,错误的模式已经在生产中使用了几年,并且有数百个存储过程,并且有数千行代码从中写出来.那么如何才能将模式转换为正常工作？

这是一个完整的数据库重构目录:

http://databaserefactoring.com/