做过后端的人来说说重构迁移数据库难度大吗

[qiaoqiao881100]

业务耦合性高，基本就是一坨屎，而且还是国内不入流的技术栈 c#, 现在要想重构，先从数据库迁移开始，之前没干过迁移这种事情， 这事情难度大吗，现在基本就让 AI 搞，也不知道最终会不会搞好。
人和库有一个能跑就行

[chachi]

c#也有.netframework 和 netcore
看你哪种了。

[liuzhedash]

不要重构，也不要迁移，百分之百炸
建议再包一层，然后另起炉灶

我是过来人，信我

[OutOfMemery]

楼上+1 ，最好是另起炉灶。。。。

[spacebound]

有句老话怎么说来着“重构一时爽，测试火葬场”哈哈哈哈
看你的项目规模和业务负责程度了。你再用 ai 也只能帮你转换 sql 语法，写写数据导入导出脚本，你要指望着 ai 帮你重构整个数据库，那基本完完～
总结：能跑就不要动

[mikawang]

慢慢迁移吧，新老库同时运行，CDC 从老库同步过去，出问题了能立马切回去，反正要有兜底方案

[jydeng]

难度非常大

[2020diyige]

重构的难度比新做可大多了，，绝大部分情况重构没有意义

[NoKey]

有些重构，其实就是相当于重新做啊

[coderxy]

难度大，做好回滚方案，除非你随时准备好跑路
一般都是先双写、然后同步旧数据、再双读验证、再把读切到新库、最后跑一段时间，没问题把双写关掉。

[loryyang]

迁移还好，重构那是风险很高。但以你的描述，你想解决架构腐烂的问题，那还是得重构啊。这事，我建议是，你至少先运维老系统一年，再提重构的事情。你没摸清楚之前千万不要重构

[xiaomushen]

不大，还好

[play78]

我不太清楚你的业务场景。说说我的。
公司内部一个供应链管理系统，就是简单的库存管理+行业特性。
技术上+数据库完全重构。难不难？不难！开发 4 个多月就重构完了。
因为数据是动态的，不能有错误，否则库存对不上。
1. 花了一个周末过来进行数据迁移（花了一个星期，做数据转换脚本，周末才执行）
2. 业务部门配合并行 2 套系统，期间，所有数据录两遍（操作逻辑还不太一样）、数据报表互相验证，半年！
你就说业务部门肯不肯陪你这么玩吧。
为什么需要半年，因为数据流不一样，新系统多了很多中间生产状态，更加精细化了，而一个产品生产周期平均需要 2-3 个月。

[yanguangs]

重构 99.9999%的情况下没有意义

现在用 AI 来搞, 最明显的就是会超出上下文长度, 现在就是限额

我之前搞一个需求, 一个 json 字段,tree 结构,打平存储到三张表里面,
就这个需求,因为 token 限额跟 vibe coding 流程调优, 都搞了快 2 个星期, 同时还要不耽误其他的功能开发

吃力不讨好, 领导关注的, 跟你关注的完全不是一个点.

领导一不给经费去买 coding plan ,二要你不影响其他功能.

[pony2335]

难度巨大无比，别干，而且必炸，有 AI 也不好使

[PopRain]

迁移数据库是迁移数据库，重构是重构。。。。
迁移数据库大部分 ERP 系统不会特别难，数据库语法基本接近，估计 AI 也能帮忙
不理解业务，就不要去重构

[nofishing]

c# 不挺好的吗，数据库不会是 sql server 吧，要换成啥？

[wangritian]

没太理解为什么是先从数据库迁移开始，不应该是先开发新系统，最后迁移数据吗
如果没办法一口气开发完，就开发一部分然后把老系统的对应代码改成远程调用
迁移数据也没什么麻烦吧，原始数据保留不动，让 AI 反复写迁移脚本+人工测试不就完了

[qiaoqiao881100]

@nofishing 对，业务系统的数据库就是 sql server ,老板目标是最终想用 go 重构整个系统，现有 c#的系统太垃圾，有部分数据库是用 mysql 的，所以现在想先把业务上的 sql server 数据库迁移到 mysql, 然后再把我负责的业务用 go 重构 解耦。

[qiaoqiao881100]

@wangritian 想先把业务上的 sql server 数据库迁移到 mysql, 然后再把我负责的业务用 go 重构 解耦。

[qiaoqiao881100]

@wangritian 我他妈也不知道为什么就我负责的这块先重构，让我先搞，业务系统那么庞大呢。我日了