我正在使用一个拥有大约十年客户数据的遗留应用程序。这些数据中的大部分不用于日常运营，但存在业务要求，在客户从系统退休之前，这些数据可供客户使用。
我们正在探索将数据存档到现有数据库的副本，然后在某个时间点之后从生产中清除记录。
我担心的是，由于开发工作，数据库每个季度都会发生重大的架构更改。
如果我要归档数据的镜像副本，我是否还需要应用每一个与生产不相符的更改脚本？
有没有替代策略？似乎无论您选择哪种存储形式（即数据库、平面文件、xml），您总是需要某种方式将旧模式映射到新模式。
AskOverflow.Dev
在考虑解决方案之前，您需要更具体地定义您的需求：
为什么需要归档？听起来系统已经在处理旧数据了，那么业务需要什么来分离这些数据呢？表现？
存档数据是只读快照，还是可能更改历史数据？如果可以更改，将支持哪些类型的更改（插入、更新、删除或它们的某种组合）？
数据库是否是多租户的，如果是，您是否要求每个租户能够在不同的时间点进行归档？
您的应用程序是否需要以归档数据作为数据源运行？我假设是的，因为您提到同步架构更改。
您需要支持的 DBMS 的最低版本/版本是多少？这将确定哪些功能可用于您的策略。
您有多少时间来实施归档？归档是一个非常底层的设计问题，理想情况下应该从一开始就做好；稍后添加它可能需要大量时间来重新设计和实施。
说了这么多，我会建议你的一件事是：如果可能的话，避免使用多个数据库，特别是如果你需要编辑历史数据的能力。
虽然我不能透露我们的 IP，但我会告诉您，如果您采用像我们对约 700 个表所做的动态方法，将数据从“实时”数据库转移到“存档”数据库的过程非常复杂. 根据您的数据库模式的状态，这种事情甚至可能无法完成，或者导致您不期望的数据差异。如果您没有很多表（< 200）并且架构处于粗糙状态，老实说，不要采取动态方法，或者等到它被清理到一个体面的状态。对于大量表和粗略的架构，多个数据库不是一个可行的解决方案。
正如您所提到的，您确实必须针对多个数据库运行更新脚本，并且您必须以某种方式跟踪所有数据库。事情变得不同步真的很容易，例如，存档数据库被移动到不同的服务器或实例，而您的配置数据库或表保存旧信息。选择要么始终同步模式，要么将应用程序编写为始终向后兼容。（提示：同步模式要容易得多。）
虽然我当然不推荐多个数据库，但根据您的要求，这是一种可能的解决方案。