这是一个创建于 759 天前的主题，其中的信息可能已经有所发展或是发生改变。
本人负责医疗系统的开发，使用 JAVA 语言。由于会接触到多个产品，就会遇到类似在 A 产品中身份证参数叫 CARD_NO ，B 产品中身份证叫 ID_NO ，这个是参数上的差异性。在 A 产品中，性别字典为男 1 女 2 ，在 B 产品中为男 0 女 1 ，这个是字典上的差异性。现在想统一规范起来，用同一套规范执行。想看下 V 友们有没有好的建议，一个是能有好的方式将规范规约起来，另外一个就是真正做到有执行力，能落地，甚至于强约束。毕竟规约出来了，如果只是纸面上，也不见得每个人都能遵守。
 |
1
nothingistrue 2022-10-11 09:34:05 +08:00  1
非技术的问题，不要想通过技术解决。
|
 |
2
leeqingshui 2022-10-11 09:42:59 +08:00
数据字典这个功能应该放到一个基础模块当中，其他组件引用就好。
多产品的不同参数含义一样，名称不同，那么应该抽离一个专门的模块做字段映射，比如说公司内部的产品三方调用各种外部接口，最终接口的参数经映射统一后落到公司内的数据库，后续看日志想知道外部传递了哪些参数过来，以你映射后的参数为基准即可。 对于你司内部产品应该也是互相调用吧？那经过这个中转映射模块就好。 |
 |
3
ohoh 2022-10-11 09:52:50 +08:00
医疗行业内部都没个规范，这个才是头疼的。如果只是文中的描述，这个仅仅是个映射而已。
|
 |
4
lookStupiToForce 2022-10-11 09:58:01 +08:00
|
|
5
lookStupiToForce 2022-10-11 09:58:19 +08:00
|
 |
6
LaGeNanRen 2022-10-11 10:00:01 +08:00
还是那句老话，如果应该是产品去对接的事情或者销售去吃饭解决的事情，请不要妄图用技术去解决 ：）
|
 |
7
masterclock 2022-10-11 10:05:48 +08:00
这能统一就怪了，国足连续夺冠 100 届、Hurd 开发完成都更有可能性
|
 |
8
vevlins 2022-10-11 10:10:47 +08:00
之前想过做一个从业务字典到数据库建表的工具，到建表 /修改表结构时可以进行自动对比和审批，把口子收在一起，要比单纯地依靠纸面规则好一些。
|
 |
9
caijunxiang1129 OP @leeqingshui 目前我司关于数据字典的思路和老哥你是一样的，通用基础模块引用。至于中转映射，也是一种方案，看内部能否实践下去，之前在单产品中有使用过类似的思路，就是将外部厂商参数进行映射转换，效果不佳，主要是配置的内容太多，时间长了，接手的人多了，实际落地实践有些问题，映射参数东漏西漏。所以现在的思路是想从源头遏制住，从一开始的内部参数定义就保证一致，外部和内部的衔接通过映射。
|
|
10
caijunxiang1129 OP @ohoh 嗯，但仅仅是这个问题，已经让做多个项目变得极其麻烦，所以先解决一些问题比啥也解决不了来的强
|
 |
11
cnuser002 2022-10-11 11:53:43 +08:00
听你意思，感觉是想达到书同文、车同轨这种效果啊。
那好像只能写一个取名清单，类似代码规范，让系统开发者遵守。 如果目的是不同模块互相交流方便。那还是要定一个规矩。 然后要么上面写个统一的模块，让下面系统引用 要么底下每个系统按规矩去写转换函数。 |
 |
12
laozhoubuluo 2022-10-11 12:31:15 +08:00
可以考虑建设一套客户中心系统，所有客户信息都存储在客户中心系统内，各个业务系统只允许存储 CUST_ID 而不允许存储客户中心系统内的客户信息，需要相关信息统一走接口到客户中心系统获取。
另外客户中心也可以作为和第三方系统联调的渠道，第三方系统调用 /回调数据统一先到客户中心，客户中心转换好之后再发给业务系统，业务系统处理完成后由客户中心封装好后进行回调，这样还降低了每个业务系统团队单独和其他第三方系统联调的成本。 |
 |
13
westoy 2022-10-11 12:37:46 +08:00
这种真能统一规范， 裁员率怕是又要爆增了
|
 |
14
xuanbg 2022-10-11 12:50:34 +08:00
首先，这是一个开发规范问题，并不是一个纯粹的技术问题。通过转换什么的不切实际，就别想太多了。要解决这个问题其实也不难。
1 、你要先把公共的字典管理模块做出来，让业务能够定义字典。先给出新的标准，然后才能谈其他。 2 、让各业务模块调用字典模块的接口来获取字典值。以后都使用相同的标准，不再产生垃圾数据。 3 、根据字典的标准值，更新数据库中的旧值为新值。更新完，系统里面的字典值就统一啦。 |
 |
15
wellerman 2022-10-11 13:33:59 +08:00
字典这玩意本来主要就是给前端用的。我的做法只要是通用的字典就在 infra 全局常量包下加一个枚举，不通用的放模块常量包下，数据只增不改。所有的数据以枚举文件为准。同时操作时也仅是用枚举字段名，根本不用关心值。
|
 |
16
james2013 2022-10-11 15:42:18 +08:00
如果你是 CTO 或者后端管理角色，能够推行下去
如果你是开发，想多了，别人凭什么要听你的？ |
|
17
caijunxiang1129 OP @westoy 哈哈，老哥看问题角度刁钻
|
|
18
caijunxiang1129 OP @cnuser002 对的对的，我们项目太多，管不过来，就是想强约束规范，书同文、车同轨一语中的
|
 |
19
Maxwe11 2022-10-11 23:35:50 +08:00
我做了很多，结果都失败了；
我原来是做大数据团队的，在系统和应用研发的后端，但是业务原因，我们的诸多业务都是依赖数据的，而且规模也大，对这个我是真的深恶痛绝； 以前重构系统，我们做过词汇提炼，设计过库表字段的词组结构和命名语法，在内部技术站发布，在重新研发新系统的时候也进驻，然后为了确保统一，都主动在实施前主动要求增加流程，把同一语义作为一个审核流程环节加进去，但是又怕研发兄弟姐妹们嫌弃我事儿多，所以还主动把事儿接过来，拿到新数据结构，让我们团队给统一梳理做完命名后再发回给研发团队…… 各种事儿，前前后后做了不知道多少； 最后依然是鸡飞狗跳，这个东西吧，就是得从建团队的时候，研发老大得把这个东西当成一种文化来建设，不然等到团队规模大了，系统应用多了，完全就是无组织无纪律； 我们和系统 /应用研发团队的矛盾很多都基于此，系统 /应用研发团队主要看业务逻辑是不是通，其他的不管，但是就没考虑过做大之后，我们在后端要应付的麻烦有多少，反正到最后我放弃了，跟团队的兄弟姐妹说，咱们自己的数据系统命名就叫垃圾回收站，寓意不管系统应用那边怎么折腾怎么用，反正数据丢回来我们在这里重新分类清理当成再生资源，都处理好再返回给各个系统； 回首往事，提起这些都是泪。 |
 |
20
waterlaw 2022-10-12 18:07:55 +08:00 via Android
数据库统一命名规范，术语规范
|
Select Language