这是一个创建于 2493 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景： 目前大多数因为用的是 MySQL InnoDB 引擎
在建表过程中，有许多类型字段，使用 tinyint 格式保证可扩展性，例如支付类型、订单类型、用户类型等等，但是随着业务的增长，类型种类越来越多，比如我们支付方式支持快二十种了。
问题： 经常需要帮忙做一些临时统计，了解数据表最快的方式就是看表注释、列注释，所以希望列注释越详细越好，但目前修改列注释的方式只有 alter table 的方式，这种方式到导致整张表进行重建，非常影响性能，也不安全
怎么保证在业务不断发展过程中，让字段的注释能够详尽呢？
现在想到的方案：
- 把每种类型的描述写到文档中、代码中（道理都懂，大家都比较懒，谁愿意去翻文档）
- 设计一张通用表，把不同的字段、描述都记录到这里面（但我并不想增加复杂性）
请求上面的方案是否有合适的，或者有更好的方法？
备注： imformation_schema.columns 中没有权限修改
 |
1
odirus OP 自己坐沙发
|
 |
2
akira 2018-01-04 15:04:24 +08:00
咦？字段注释不是另外去维护的么，怎么可能维护在线上表里面哦。
|
 |
4
WuwuGin 2018-01-04 15:48:03 +08:00 via Android
专门在开发环境写一个 get 注释方法，然后开发的时候直接以只读方式写进去。又不想看注释，文档，感觉这样比较靠谱。
|
 |
5
hcymk2 2018-01-04 15:52:06 +08:00
同步一个空的数据库， 注释写在这个库上面。
|
|
6
odirus OP 刚刚我也请教了一下其他人，给出的建议是：建一个业务字段表，结构类似于,
seq_id, type_id, id, name 我们部分字段也是这样做了。但有些字段最开始以为只有一两种情况就没写进去，结果根据业务需求，类型越来越多，然后就尴尬了。 |
 |
8
depress 2018-01-04 16:19:35 +08:00  2
我们 DBA 不是大佬，但是以下这套流程是她提的，给你参考。
开发人员会面对三个库，本地库、测试库、线上库。 线上库不维护注释，基于安全考虑。 本地库是开发人员自己电脑里的，随便改，供开发用。 测试库供开发人员测试用，和线上库结构一致，就是多了注释，但开发人员没有权限动结构。 如果开发人员对库有增删改需求，会先改自己本地库，不影响开发，之后向 DBA 提需求，DBA 在初建库时会维护一套数据字典文档，把所有字段和注释维护进去，如果是字段注释的修改需求，直接维护数据字典，如果是增加字段的需求，会先看数据字典有无相同意思的字段可用，有就直接用，没有就看开发人员提的字段名是否合理，合理的话维护进数据字典，完成需求后通知开发人员去测试库查看，开发人员再对应修改本地库和代码，当测试库测试没问题会对线上库做修改。关于测试库及线上库的修改都会用脚本在凌晨进行，顺序是备份整个库→备份会修改的表→做修改→上班后看运行是否正常，正常就删掉备份的表，不正常就恢复备份库。 |
Select Language