我们公司的旧版遗留系统有如此糟糕的数据库设计（没有外键，带有序列化PHP数组的列等等）。我们决定用新数据库架构从头开始重写系统。
我们想要按部分重写系统。因此，我们将旧的单片应用程序拆分为许多较小的应用程序。
问题是：我们希望在两个数据库中拥有实时数据。新旧架构。 我想问你是否有人知道如何做到这一点的最佳实践。
我们的想法：
非常感谢
答案 0 :(得分：0)
过去我不得不处理类似的问题。有一个系统没有支持，但有人使用它，因为它有一些功能（安全漏洞），使他们具有某些功能。但是，它们也需要新的功能。
我选择了涉及新系统的表，我创建了一些交叉更新表的触发器，所以当我在旧系统上创建一个寄存器时，触发器在新系统中创建了一个副本并进行了反转。如果你正确地设计这个系统，你可以让两个系统同时实时工作。
缺点是，当两个系统都在运行时，系统会变慢，因为你必须在每个操作中保持两个数据库的完整性。
答案 1 :(得分：0)
我将启动，方法是添加一个数据库层来接受来自业务层的API调用，然后写入旧架构和新架构。这会增加前面的复杂性，但它可以保证数据保持同步。
这需要更改旧系统以调用API而不是发出SQL语句。如果他们原本没有先见之明，那么你可能无法接受我的方法。但是，你应该继续前进。
触发器可能有效，也可能无效。在旧版本的MySQL中，给定表上只能有一个给定类型的触发器。这会迫使你将不相关的东西归为一个触发器。
复制可以解决某些更改 - 引擎，数据类型等。但它无法帮助将一个表拆分为两个。注意触发器的复制以及触发器有效的位置（主站和从站之间）。 通常，应该在Master上执行存储的例程，让效果复制到从属。但是可能值得考虑如何在Slave中运行触发器。或两个服务器中的不同触发器。
另一个想法是分阶段进行转型。通过仔细规划模式更改与触发器的应用与代码更改与数据库层的比较，您可以一次进行一次部分转换，有时无需大量中断即可同时更新所有内容（用手指交叉）。一个简单的例子：（1）更改代码以动态处理新的或旧的模式，（2）更改模式，（3）清理代码（删除旧模式的处理）。
答案 2 :(得分：0)
考虑到数据的复杂性和表的结构，进行数据库迁移可能是一项繁琐的工作，当然没有任何约束或适当的设计。但鉴于您的遗留应用程序正在完成其工作 - 损坏的可用数据量将是最小的。
对于上述问题，我建议使用db迁移任务，将所有旧的遗留数据转换为新的表单。并开发新的应用程序。优点是。
1）不需要保留2种不同的应用程序。
2）无需更改遗留应用程序中的代码 - 这可能会变得混乱。
3）数据库迁移将使我们有机会纠正任何损坏的数据（如果需要）。
在所有情况下，数据库迁移可能都不切实际，但如果您可以花费较少的工作量而不是为数据库同步进行更改，那么遗留应用程序的新api也是如此 - 我建议您继续使用它。