什么是有关如何转换到更好的架构的一些提示,而不会破坏所有依赖旧的代码的代码？我会提出一个具体问题,我必须说明我的观点,但是可以自由地就已经证明有用的其他技术提供建议 – 这些技术也可能派上用场.

我的例子：

我公司接收和运送产品.现在,产品收据和产品出货具有与之相关的非常不同的数据,因此原始数据库设计者为收据和出货单创建了单独的表格.

在我使用这个系统的一年中,我已经认识到,目前的模式并没有令人.目结舌.毕竟,收据和出货都基本上是交易,它们各自涉及更改产品的数量,只有/ – 符号不同.事实上,我们经常需要找到产品在一段时间内改变的总量,这是一个完全难以处理的设计问题.

显然,适当的设计将是具有单个事务表,其中Id是ReceiptInfo或ShipmentInfo表的外键.不幸的是,错误的模式已经生产了几年,并且有数百个存储过程,并且有数千行代码被注销掉.那么我怎么能将模式转换成正常工作？