我们有一个案例管理系统的数据库，它早就应该对几个核心表进行一些重构，以便根据列相关的业务领域将它们分开。
所有关系将继续是 1：1，我们只是想避免让 EF 模型必须引用这些巨大的表，因为有一种驱动力是能够独立于其他区域部署系统的某些区域，由于数据库结构，这目前是不可行的。
表1有病例数据和415列，表2有个人数据和564列。
两者都有10多个复杂的触发器，并且都由传统的Delphi前端，Winform项目和其他使用EF的.NET项目直接引用。 因此，我一直在尝试提出一种解决方案，以允许我独立于更新系统的所有各种前端来重构表。
我大约完成了以下计划的一半：
- 将视图创建为(从 [表 1] 中选择 *((使用架构绑定以确保定义保持不变(
- 更改引用表的所有现有视图的定义，以查看新视图
- 将表重命名为 [Table_1_legacy]
- 将视图从步骤 1 重命名为 [表 1]
- 更改所有现有视图的定义以指向 [表 1](现在是视图！
- 在新视图上创建 INSTEAD OF 触发器
- 重构 [Table_1_legacy]
- 将视图更改为多表，查看新的重构表
- 更改 INSTEAD OF 触发器以更新/插入到新的重构表
- 慢慢更改所有前端以删除对 [表 1] 的引用，并替换为对新的、较小的重构表的引用......
我的绊脚石是原始表上已有的复杂触发器，这些触发器具有包括联接在内的更新，这些更新不再与带有 INSTEAD OF 触发器的视图兼容。 如果我禁用这些，我的概念证明就可以工作，据我所知，我们的 Delphi 和 EF 都可以与新视图无缝协作。
我的问题：我是否完全走错了路，还是值得坚持重写/删除麻烦的现有触发器？
当有如此多的独立前端代码直接引用数据库结构时，是否有已知的重构数据库的策略？我看不到引入数据层以从数据库中抽象出来的方法，而不会意外地遗漏位置。
我不会打扰现有表格。而是创建新表(根据需要(并将前端更改为指向新表。然后将数据迁移到新表中。这将是顺利的过程。