1
janus77 2020-11-05 12:46:42 +08:00
数据库还会不兼容吗……不都是那几个
|
2
EminemW 2020-11-05 12:47:55 +08:00 via iPhone
?看需求
|
3
loliordie 2020-11-05 12:49:23 +08:00 via Android
看你结构有没有改过 比如说重写架构 有可能储存结构也改了 那需要导入
单纯重写的话 逻辑不改 当然可以直接重用 |
4
boris93 2020-11-05 12:49:39 +08:00 via Android
数据库跟应用又没关系
无非是再配置一次数据库连接罢了 |
5
hambman OP |
6
hambman OP @loliordie 不同的语言会用到不同的 ORM, 具体说 flask (sqlalchemny) 迁移到 golang (gorm),
高级一些的数据库功能,比如多对多的关联,或者数组字段,不同 ORM 也许有不同实现。 想问问大家有没有遇到这个问题,或者是我多虑了? |
7
hoyixi 2020-11-05 12:55:46 +08:00
顺序反了,你在开始重写的时候,首先是设计数据库,直接重用原有数据库?还是变更?然后才会重写应用。不然你写个啥
|
8
imycc 2020-11-05 12:58:43 +08:00
复用数据库的话按照之前的模型定义再写一层 ORM 就好了吧。如果是直接用 SQL 的甚至不用换。
如果是旧系统重构,原有的数据结构太乱了想换掉,那就重新设计吧。 |
9
kop1989 2020-11-05 13:30:31 +08:00
从我的实际理解看,是否重构数据结构和应用代码的重构 /重写完全没关系。
也就不存在你考虑得这个问题。 如果是仅仅探讨技术上的可能性的话,那就要先考虑数据结构是否继承,再考虑 dao (数据链路)的实现方式。而并不是反过来。 从技术上讲:一个成熟的技术语言生态,一定是有成熟的解决方案来适配绝大多数数据库,以及库表结构的。(前提是你的需求合理) 从软件工程上讲:数据结构是业务信息化实现的根基。非必要(不是因为业务变更,性能问题等)的数据库表结构的重新梳理,带来的副作用很大,工作量更是难以预期的。 所以完全没有必要因为你更换了应用 /业务层的代码实现,而去考虑是否重新梳理数据库。 |
10
snowhunter 2020-11-05 19:00:58 +08:00
@hambman 复杂应用还是裸写 sql 好。尽量不要用 ORM 的高级特性
|
11
hambman OP |