【问题标题】:Gradual migration to a new database schema. ¿Suggestions?逐步迁移到新的数据库模式。 ¿ 建议?
【发布时间】:2010-08-06 20:56:01
【问题描述】:

(这个问题是关于暂时并以编程方式保持两个数据库的新记录同步的最佳方法,具有非常不同的架构,并忽略旧的过时且不再需要的记录。)

我在一家为指南、报纸和网站提供电视节目信息的公司工作。

我的旧系统有几个限制,正在被新系统取代。

不同的客户端以不同的格式(xml、sql、txt,甚至可打印的 PDF)和不同的方式(推送、拉取、部分转储、简单导出、人工辅助导出 - 如 PDF 版本 - 等)获取数据)。有些导出每月生成一次,有些则每天生成一次以上。

问题在于,在新系统完全开发和加载之前,几个客户端必须依赖旧系统中的数据,而维护数据的工作人员无法使两个数据库同步,因为这需要大量额外的工作,但考虑到项目的规模,一夜之间切换系统似乎是不可能的。

我们不想将旧数据库中的数据完全导入到新数据库中,因为大部分已经没有必要了,并且有很多垃圾(即不同详细级别的重复记录,我们只需要存档的旧播出信息)。

我们希望将新记录插入到两个数据库中,并将正在编辑的旧记录也复制到新数据库中。

我们即将开始使用 Symfony 和 Doctrine 开发新系统,我决定我们可以设计一组 ORM“代理”类,它们应该具有与简单的 Doctrine ORM 类集相同的接口,但要在另外两组类(与新系统接口的类和与旧系统接口的类)之间保持同步。最终旧的 DB 应该与代理类一起被丢弃,直接连接到新 DB 的 Doctrine ORM 类应该取代那个位置,就好像旧的系统永远不会存在一样。

这是一个长远的目标,我对这种方法并不完全有信心。
有人有这种项目的经验吗?
您是否知道这种方法中的任何常见缺陷,或其他适合这种情况的解决方案?

【问题讨论】:

    标签: database design-patterns language-agnostic oop migration


    【解决方案1】:

    我不确定是否有方法可以做到这一点,我只能建议您在开始迁移数据之前对新数据库进行全面测试,一旦您确定它可以正常工作,我建议您编写一些迁移将查询要从旧数据库导出的所需数据的应用程序,您不必(但您应该)调试旧数据库中的数据,如果新数据库有效,则限制应忽略重复的数据.

    我曾经在一家不关心这类问题的公司工作,到头来那是一团糟,一个接一个的补丁,大喊大叫和不必要的压力。我知道……伤心。

    【讨论】:

      猜你喜欢
      • 2011-04-07
      • 2023-04-03
      • 2020-09-02
      • 1970-01-01
      • 2020-01-22
      • 2017-09-21
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多