好的，这是我们正在面临的问题。
目前：
我们试图实现的：
我们遇到的问题是如何实现此迁移，不仅涉及应用程序，还涉及数据库。
我们目前的解决方案是：
但是，在讨论此过程时，我们正在考虑需要两次重写新的Web服务。一次是为了旧数据结构，一次是为了新数据结构，因为目前我们无法表示旧数据结构以适应新的Web服务。
我想知道是否有人面临过这种挑战，以及如何克服这些问题/实现等。
编辑：更多有关使用双向触发器同步的解释；更新了语法、语言和清晰度。
我在一家大型网络应用程序上工作了7年，面临着类似的数据模型升级问题，所以我理解你的困境。基于这种经验，我提出了一些有点不同但希望更容易实施的建议。首先，有一个观察:
对于组织而言，价值在于数据——数据将长时间存在，超越所有当前应用程序的生命周期。企业将不断发明新方法来从捕获的数据中获取价值，这将产生新的报告、应用程序和业务方式。
因此，正确地获取新的数据结构应该是最重要的目标。不要为了其他短期开发目标(特别是以下内容)而牺牲获取正确的结构:
这个结构会随着时间的推移而改变，因此您的架构必须允许频繁添加和不经常正常化它。这意味着您的数据结构和任何共享的API(包括RESTful服务)必须得到适当的版本控制。
你提到你将“将所有功能移动到RESTful服务中，以便没有应用程序可以直接访问数据库”。我需要就传统应用程序提出一个非常重要的问题:这很重要吗?它带来了什么价值?
我之所以这样问，是因为:
而其他交叉关注点则没有改变:
您可以通过维护遗留 RESTful API 来迁移数据库并保持遗留应用程序运行。但是，如果我们不引入“遗留”RESTful服务，而是保持遗留应用程序呢。
假设大部分“遗留”应用程序使用 SQL 直接访问数据表; 您可能还有许多数据库视图。
一种数据迁移方法是：新数据库（以新架构中的新范式结构为基础）将旧结构作为< strong>视图 向遗留应用程序呈现，通常来自不同的模式。
实际上这很容易实现，但仅解决报告和只读功能。那么遗留应用程序 DML 呢？DML 可以使用以下方式解决：
具有双向同步功能的遗留格式表，使用触发器与新格式表进行同步是一种粗暴的解决方案，相对丑陋。您最终会在两个不同的模式（或数据库）中拥有相同的数据，并且如果同步代码存在错误，则可能导致数据不同步 - 然后您就会面临“两个主人”的经典问题。因此，请将其视为最后的手段，例如当：
当需要对数据进行这种更改时，代码和逻辑会有一些重大变化。您可以实现兼容性层（优点：不更改旧代码）或更改旧应用程序（优点：数据层干净）。这是工程团队的技术决策。
使用上述方法创建遗留结构的兼容性数据库可最大限度地减少对旧应用程序的更改（在某些情况下，旧应用程序甚至不需要进行任何代码更改）。这极大地降低了开发和测试成本（对于业务来说没有净功能收益），并极大地降低了推出风险。
它还使您能够集中精力关注组织的真正价值：
请不要将上述内容解读为反对web服务，特别是RESTful web服务。当用于正确的原因时，例如用于启用web应用程序或在不同系统之间进行集成时，这是一种良好的架构解决方案。然而，在数据迁移期间管理您的旧应用程序可能并非最佳解决方案。
首先，这似乎是一个非常混乱的情况，我不认为有一个“干净”的解决方案。我曾经经历过类似的情况几次——它们并不好玩。
首先，更改客户端应用程序的工作量将是巨大的——如果基础域发生变化（例如引入与人分开的地址的概念），客户端应用程序也会发生变化——这不仅仅是访问数据方式的变化。避免这种痛苦的最佳方法是编写您的 API 层以反映未来的业务域模型，并将旧的数据库架构粘合到其中；如果有新的概念您无法使用旧数据反映（例如“get /app/addresses/addressID”），则抛出 NotImplemented 错误。在您可以使用旧数据反映新模型的地方，尽可能将其连接起来，然后在幕后进行重构。
其次，这意味着您需要将版本控制作为API的一级关注点 - 这样您就可以告诉客户端，在版本1中，功能x、y和z会抛出“NotImplemented”异常。每个版本都应向后兼容，但添加新功能。这样，您可以在版本1中重构功能，只要不破坏服务，并在版本1.1中实现功能x，在版本1.2中实现功能y等。最好为您的版本制定路线图，并在停止支持某个版本或发布破坏性更改时通知客户端应用程序所有者。