大家在工作中是否都用数据迁移?

以前用其他框架的时候,从来没使用过数据迁移,现在学习 Laravel,想知道大家在工作中是否都使用数据迁移

《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
最佳答案

公司项目绝不可能让你用,让你用的公司要不就没有好的技术leader,要不就没有啥规模。

几个场景如下

  • 分表规则通过migrate?每天新增表跑你的 migrate?一定是dba做的。
  • 还是分表,分表的数据表你migrate添加字段?索引?
  • 归档表,单表3kw以上生产数据库你一个migrate就开始跑DDL了?
  • 你一个migrate里一会儿addColumn,一会儿dropColumn,你猜dba会不会揍你(不骂,直接动手)
  • 上线流程,先执行migrate还是先同步代码?
  • 还是上线流程,有错误需要撤回当前版本,代码已经紧急撤回了你的migrate呢怎么回滚?
  • 最后,还是上线流程,你们家dba允许开发染指数据库?

migrate这种东西只能用于本地开发或者小项目跑跑或者单元测试给memory sqlite用。

8个月前 评论
mshx 8个月前
goodgood 8个月前
TalentMiao 8个月前
fansheng 8个月前
cevin (作者) 8个月前
讨论数量: 44

公司项目绝不可能让你用,让你用的公司要不就没有好的技术leader,要不就没有啥规模。

几个场景如下

  • 分表规则通过migrate?每天新增表跑你的 migrate?一定是dba做的。
  • 还是分表,分表的数据表你migrate添加字段?索引?
  • 归档表,单表3kw以上生产数据库你一个migrate就开始跑DDL了?
  • 你一个migrate里一会儿addColumn,一会儿dropColumn,你猜dba会不会揍你(不骂,直接动手)
  • 上线流程,先执行migrate还是先同步代码?
  • 还是上线流程,有错误需要撤回当前版本,代码已经紧急撤回了你的migrate呢怎么回滚?
  • 最后,还是上线流程,你们家dba允许开发染指数据库?

migrate这种东西只能用于本地开发或者小项目跑跑或者单元测试给memory sqlite用。

8个月前 评论
mshx 8个月前
goodgood 8个月前
TalentMiao 8个月前
fansheng 8个月前
cevin (作者) 8个月前
陈先生

用!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!超大声

8个月前 评论
v_cszhang (楼主) 8个月前
陈先生

用!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!超大声

8个月前 评论
v_cszhang (楼主) 8个月前

至少我不用,A分支和B分支同时修改数据库上线可能会有一定的麻烦,看文档会写就行了,用的时候现看文档,没必要浪费时间。

8个月前 评论
喝卵形 8个月前
goStruct

人多的时候用这个很不方便,除非个人开发。

8个月前 评论

这东西可用可不用,因为在国内大多都是要求效率不要质量的,所以来回改迁移文件没直接改数据库简单

8个月前 评论

个人项目会用 公司项目看公司规定

8个月前 评论

第一家公司一直在用,个人习惯后觉得很方便,后面公司都没有用,都是直接修改数据库然后记一下sql,个人觉得不方便

8个月前 评论

公司项目绝不可能让你用,让你用的公司要不就没有好的技术leader,要不就没有啥规模。

几个场景如下

  • 分表规则通过migrate?每天新增表跑你的 migrate?一定是dba做的。
  • 还是分表,分表的数据表你migrate添加字段?索引?
  • 归档表,单表3kw以上生产数据库你一个migrate就开始跑DDL了?
  • 你一个migrate里一会儿addColumn,一会儿dropColumn,你猜dba会不会揍你(不骂,直接动手)
  • 上线流程,先执行migrate还是先同步代码?
  • 还是上线流程,有错误需要撤回当前版本,代码已经紧急撤回了你的migrate呢怎么回滚?
  • 最后,还是上线流程,你们家dba允许开发染指数据库?

migrate这种东西只能用于本地开发或者小项目跑跑或者单元测试给memory sqlite用。

8个月前 评论
mshx 8个月前
goodgood 8个月前
TalentMiao 8个月前
fansheng 8个月前
cevin (作者) 8个月前

doctrine的enentity管理数据库最方便了

8个月前 评论

不是很好用,最开始是每个人自己本地的数据库使用,后面干脆只记录每次开发需要变更的sql语句,共用同一个测试数据库,生产环境 将记录的变更sql语句发给DBA或者你的leader

8个月前 评论
sanders

:sweat_smile: 我们也在用哈,可能是公司规模太小了,没有运维组,也没有 DBA。基本上几个骨干工程师都能兼任一部分,我收集并撰写迭代发布文档并负责发布上线。

其实还是跟各个团队的发布流程相关,肯定不是所有人都有生产环境账号的,有账号的人要分配权责,负责好自己承担的任务。

置于具体细节,是否可以执行回滚,那其实是发布细节的问题。一般是不执行回滚的,因为非常麻烦,需要制定相应的回滚方案。执行迁移也不都是随部署执行的,比如发布前需要搞清楚,新的代码是否兼容旧版本数据库结构,如果完全兼容便可放心的执行部署后迁移。否则,我们会先升级一个维护专用的 POD (我们这里用的k8s集群),在这个 POD 容器中执行迁移和其他需要在部署代码前完成的准备工作,然后在升级整个集群。

8个月前 评论
cevin 8个月前
陈先生

不是太懂这个 "最佳答案"

8个月前 评论
徵羽宫 8个月前
v_cszhang (楼主) 8个月前

可能我水平不行吧,没去过什么大公司,干过两三家公司都没有专人维护数据库。 甚至 leader 也不太操心,我做的功能模块是怎么实现的,怎么样的表设计, 功能优化之后对数据表有没有修改。基本上如果我忘了数据表有过那些修改,没有人能替我想起来, 所以我用 migrate 。

而且我感觉 migrate 真的方便测试, 比如我本地开发好了,我测试环境一拉代码, php artisan migrate 就能进行测试了。如果测试环境没问题, 生产环境和测试环境都是同样的迁移文件必然也没问题。 如果没有 migrate, 除非我每次测试环境测试前,都从生产环境备份一个数据库下来,然后再运行这一次修改的SQL语句。 不然我就总疑心测试环境的数据库和线上环境的数据库到底一致不一致。

8个月前 评论
徵羽宫 (作者) 8个月前
v_cszhang (楼主) 8个月前
徵羽宫 (作者) 8个月前
徵羽宫 (作者) 8个月前
v_cszhang (楼主) 8个月前
徵羽宫 (作者) 8个月前
徵羽宫 (作者) 8个月前
徵羽宫 (作者) 8个月前

团队合作开发的时候,migration 还是很重要的,不然一会新增个表字段,没有提交记录对其他开发人员来说很麻烦

8个月前 评论
nff93

同样不是很懂这个最佳答案,咋一上来就是分库分表、公司配专业DBA、3KW数据

8个月前 评论
cevin 8个月前
v_cszhang (楼主) 8个月前

小团队;navicat 自带的结构同步,每次上线对比下,感觉挺好的

8个月前 评论
QIN秦同学
技术永远是为了业务服务的。单纯炫技没个鸟用。
想当年刚入职小公司,那是前后端一把搂,这时候别说你跑migrate,你直接在线上改,都没人管。老板只是一句话,好了没,能用了吗?上次说的功能开发完了 吗?
后续公司搞到钱了,各种人员都到位了。你还想一把搂?运维、DBA、测试、产品、那不上来一把搂你?
有钱大家一起赚,你都搞了。别人怎么活。哈哈!!!
最后:没人管你的时候,就证明这个可行。

现在我们流程:
1、项目中必须要写 migration 文件,便于接手者了解和上手。
2、相应的 SQL 改动在自动运维平台上提交工单、
3、必须3人审核,直属领导、技术二把手、DBA点确认后,自动执行。【其实真正起作用的是 自己和直属领导】
8个月前 评论
v_cszhang (楼主) 8个月前

用吧 对自己方便点 其实很多程序员接触不到那么有规模的公司的 可能是我去的都比较low 都用migrate不用还要被说。而且都用rds,感觉没那么多问题。
再换句话说,真的有公司那么啰嗦的话,你也可以用啊,大不了转换城sql语句交给对方,migrate看起来还是要规范点的

8个月前 评论
v_cszhang (楼主) 8个月前

个人项目和几个人的小公司用,大公司有DBA了一般就不用了,千万级数据直接对字段还有索引操作是很致命的,我就干过这事,数据库卡死,也连接不进去,业务停了十几分钟

8个月前 评论
QIN秦同学 8个月前
xiusin 8个月前

不用 ,感觉不可控。sql有专门仓库管理。

8个月前 评论

小项目我都是直接使用navicat数据库对比,没用过这个。以前在一家大点的公司有运维人家直接不让我动,我只负责给sql。而且项目是多语言开发,项目还有Java的接口和C++的接口。

8个月前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!