处理模式更改的数据归档策略？

Question

我正在使用一个遗留应用程序，该应用程序拥有大约十年的客户数据。大部分数据不用于日常操作，但有一项业务要求，即在客户从系统退休之前必须有可用的数据。

我们正在探索将数据归档到现有数据库的副本中，然后在某个时间点之后清除生产中的记录。

我担心的是，由于开发工作，数据库每个季度都会经历大量的模式更改。

如果我要归档数据的镜像副本，我还需要应用每一个与生产背道而驰的更改脚本吗？

有没有其他的策略？看起来，无论您选择何种形式的存储(即数据库、平面文件、xml)，您总是需要某种方式将旧模式映射到更新的模式。

Answer 1

在考虑解决方案之前，您需要更具体地定义您的需求：

• 为什么归档是必要的？听起来系统已经处理了旧数据，那么业务需要什么来分离这些数据呢？表演？
• 归档数据是只读快照，还是历史数据更改？如果可能进行更改，将支持哪些类型的更改(插入、更新、删除或这些更改的某种组合)？
• 数据库是多租户的吗?如果是的话，您是否需要每个租户能够在不同的时间点存档？
• 您的应用程序需要将归档数据作为数据源运行吗？我假设是的，因为您提到了同步模式更改。
• 您需要支持的DBMS的最低版本/版本是什么？这将决定在您的策略中可以使用哪些功能。
• 你需要多长时间才能实现归档？归档是一个非常低层次的设计问题，理想情况下应该从一开始就把它添加到后面，重新设计和实现可能需要大量的时间。

说了这些之后，我建议您在这里完成( Server)的一件事是:尽可能避免多个数据库，特别是如果需要编辑历史数据的能力。

• 虽然我不能透露我们的IP，但我要告诉您，如果您采用动态方法(就像对大约700个表)一样，将数据从“实时”数据库转移到“归档”数据库所涉及的过程非常复杂。根据数据库模式的状态，这类事情甚至可能无法完成，或者导致数据不一致。如果您没有太多的表(< 200)并且模式处于粗糙的状态，那么老实说，不要采取动态的方法，或者等到清理到适当的状态。使用大量的表和粗略的架构，多个数据库并不是一个可行的解决方案。
• 正如您所提到的，您必须对多个数据库运行更新脚本，并且必须以某种方式跟踪所有数据库。事情很容易被去同步，也就是说，一个归档数据库被移动到另一个服务器或实例，而您的配置数据库或表保存了旧的信息。选择要么始终同步架构，要么编写应用程序始终向后兼容。(提示:同步模式要容易得多。)

虽然我当然不推荐多个数据库，但这是一种可能的解决方案，取决于您的需求。