在公司项目开发中，数据库是怎么管理的？

是什么线上 bug 需要重新初始化数据库？里面的数据先导出然后初始化之后再导入？中间的业务不就得停止一段时间？

我是在传统企业部门做 Web 开发，为了学习数据库，买了极客时间上的几门课程，理论 + 实战，你也可以考虑买来看看，了解一下在实际业务中数据库开发的方方面面。

"学校里一个还不错的技术部门里"
很显然不是技术还不错

1.Liquibase 配合 Ant 在部署阶段执行
2.发 Hotfix 版本
3.不写等着被砍，想空手过方案评审？
4.各司有自己的知识库，例如 Confluence

1. 提前初始化，就是提前把 CREATE sql 执行来建表，然后才会发布相关代码。会有 DMS 相关的站点工具部署好，然后所有的 DDL，DML 语句都预先或者事后在平台录入执行，建表会跟着需求迭代走一个流程，表结构的变更则需要审批
2. 分环境，dev 环境的新表随便玩，上线时在线上数据库当前是稳定的表结构。如果真的发现问题，那就 alter 改，但是需要审批，部分操作会有 DBA 的介入
3. 必须
4. 文档

我觉得你问这些问题，似乎是陷入了遇到问题就寻求答案的坏习惯中了。明明可以思考的更深入的。

@TheBestSivir 其实我没有你说的这个坏习惯，不过我在学校里的确对真实的工作情况不了解，之前也吃了不少亏，所以只能问下了

@liprais 是指学习氛围挺好的，大家相互促进，是那种学长带学弟的学习方式，经常开交流会，不过规范什么的的确不太行，毕竟还是学习为主，也没有个强势的硬推规范，倒是有学长进了大厂后反馈的，不过经常陷入这个圈子：在学校想改革的，没有经验，不知道怎么做，有经验的又都毕业了没时间。。

除了改进自己的开发习惯外，我也想把我所在团队的开发规范再推进一下

你这个问题有点初级了

@hhyvs111 我又看了下，的确有点

go 的话我是直接用 gorm 生成

5L 回答了我想回答的

你的这些问题只要你去公司实习一下就会知道了。
公司的要求一般为软件升级不能影响现有业务，你自己想想如何处理才能不影响现有业务就可以了

现在好像有 Flyway 这种数据库 DDL 级别的 CI/CD pipeline 了。

我们公司简单粗暴, 数据库也分开发环境、预发环境和生产环境.
开发环境所有开发人员都可以操作, 如果有需要提交到生产环境的 sql, 需要提交个数据库更新文件
开发完成并通过初步测试, 主管会用 jenkins 将这些数据库更新文件里的 sql 更新到预发环境, 进行预发测试
等所有测试通过, 进行生产环境更新

1. 现实产品开发（尤其 web ）一般不写 sql，一定会用 orm，建表让 orm 来做
2. 表一旦建好，跑在线上就极少重新初始化了，但是会因为频繁迭代而不断改变字段或结构。所以项目中往往会有专门的 migration 服务 /层；一般表的第一阶段初始化也会写成 migration，可以把初始版本纳入 migration 依赖中
3. 参考 gormigrate
4. 数据库设计文档没有用，web 开发基本只关心 API 的输入输出，使用 orm 的项目表结构会在 model 代码中有所体现，所以没有文档问题也不是很大

5. 学校的技术部门 /社团跟商业开发完全不是一回事，哪怕是清北的社团也一样不能比


6. 初始化数据库就清数据了，线上不可能这么干的。bug 最严重也就只是让后端崩掉，崩掉就重新拉起来，不是 go 吗，百分比跑在容器里的，server 容器会被容器宿主自动重启，你问的第二个问题其实是另一个维度上的了，跟现实正交

> 建表是提前在程序运行前就建立好吗？还是直接在程序中初始化？ 最近开始用到了数据库设计工具，提前设计好了后直接就生成 SQL 了，所以我想知道，你们是提前就把表初始化了，还是在运行时初始化呢？

一般不直接接触数据库，使用 ORM 为主。好处是可以少写 SQL，以及接驳不同的数据库比较容易（比如测试的时候，需要接驳临时的内存数据库 vs 开发接驳开发数据库 vs 线上数据库，这几个数据库可能类型都不一样，一套代码可以跑在不同的数据库上）。 数据模型在代码中定义完之后，使用 migration 服务生成 migration 文件（类似一些数据库指令，修改字段，创建新表等）。每次数据模型变更（删除，加减字段）之后，都需要增量生成 migrations files 。上线前，把生成的 migrations files 对着目标数据跑一边。

> 如果提前建立好，怎么自动化这个过程呢？ 经常会有线上 BUG，要重新初始化数据库，那么怎么自动化呢？直接让运维写个脚本，然后到时候 call 他让他重启吗？

玩归完，闹归闹，线上数据数据库不要随便初始化，这个属于严重数据事故。
数据结构发生变更之后，生成 migrations 文件，上线前，对着数据库跑一下这些文件即可。migrations 文件，是需要过代码审核的。 一般新增字段或者模型是最容易的，因为不影响已有的数据。变更和删除字段在一个比较成熟的线上系统里面比较少见，因为要考虑对已有数据的影响。

> 你们在开发过程中，会写数据库的设计文档吗？

用 ORM 的话，在代码的数据模型中做好文档即可。

> 如果要写的话，是用的什么工具来管理的呢？

文档写在代码里，使用标准的文档生成工具生成静态页面即可，例如 mkdoc

建表是走 DBA 的 jira 流程管理一般人工或者程序执行
建表或初始化在代码发布前执行完毕不然代码发布了可能就会告警了啊.....

发布前会充分测试,如果业务表足够大,大表加资源执行时间是超长的一旦出现问题需要回滚等等可能会直接出现 P 级事故啊...涉及到数据库的部分尽量通过人工审核等等基本不会出现问题.

会写需求设计文档中描述数据库表部分.

wiki 或者其他按公司内部要求

先思考下分层设计和一个重启了数据就全没了的应用有什么存在的必要性。