Su的技术博客

  • 首页
  • 原创
  • 视频
  • Java
  • MySQL
  • DDD
  • 事故复盘
  • 架构方案
  • AI
  • Other
  • 工具
    • AI工具集
    • 工具清单
    • JSON在线格式化
    • JSON在线比较
    • SQL在线格式化
  • 打赏
  • 关于
路很长,又很短
  1. 首页
  2. 架构方案
  3. 正文
                           

【转载】系统设计 | 数据字典方案

2023-10-30 1823点热度 0人点赞 0条评论

系统设计 | 数据字典方案


问题分析

在应用项目中,我们总会遇到很多字典项的数据,比如类型、状态等。这些数据一般是有限个可选值,在前端可能作为 Select 控件存在,用于录入、搜索等场景。

这类数据的一般作为配置存在,怎么设计才能让前后端维护方式最低呢?

我们在团队上做了很多讨论,结合过完项目的经验把潜在方案整理如下。

方案枚举

假定我们经过简单的头脑风暴,可以枚举出下面的方案,再来分析其优缺点:

  • 直接硬编码,前端编码到 Select 控件中,后端在代码中作为字符串出现
  • 统一管理到数据库,并通过 API 输出给前端
  • 放到配置中心的 YAML 文件中,并通过 API 输出给前端
  • 放到 Redis 中,并通过 API 输出给前端
  • 后端使用枚举,并通过 API 输出给前端

经过比较我整理了一份对比表格:

优点 缺点
硬编码 简单粗暴,不需要特别设计 维护困难,容易造成前后端枚举值不一致
数据库 灵活修改,可以不发布、不重启修改配置 维护困难,需要考虑每个环境的数据值
配置中心 维护简单,灵活修改,可以不重启修改配置 没有特别的缺点
Redis 和数据库类似 维护困难,数据容易丢失
枚举类 简单,代码中本来也就需要使用枚举值 需要发布服务才能使用,枚举类可能过长

在实践的经验中,以上几种方案都见到过,在选择技术方案时遵守几个原则:

  • 先方案枚举,避免先入为主
  • 抓主要矛盾,剔除干扰
  • 结合性价比,实用优先

比较下来,放到数据库的实践设计过重,因为几乎用不到需要在线变更字典的情况。而放到配置中心是一种中庸的方案,既可以灵活调整维护成本也并不高。

而 Redis 的这种方案看不到特别的优点,在很多公司也不合规。

使用枚举类直接替代字符串的数据字典维护成本低,因为服务端开发本身就需要使用枚举值,这样不需要再次和字符数据字典映射。

基于枚举类的方案还可以进一步优化,通过注解标出需要作为数据字典的枚举类,或者继承一个父类,通过反射扫描出系统所有的数据字典项,并通过 API 输出给前端使用。

参考实现

当分析出这些技术方案后,我把这个扫描枚举类的实现方式发送给 ChatGPT,得到了一个比较满意的 Demo,经过修改就可以用到项目上了。

@RestController
    @RequestMapping("/enums")
    public class EnumController {
       @GetMapping
       public List<String> getEnums() {
           List<String> result = new ArrayList<>();
           try {
               // 扫描项目中的所有类
               Reflections reflections = new Reflections("com.example");
               Set<Class<?>> classes = reflections.getTypesAnnotatedWith(MyAnnotation.class);
    
               for (Class<?> clazz : classes) {
                   // 找到实现了 MyInterface 接口的类
                   if (MyInterface.class.isAssignableFrom(clazz)) {
                       // 获取类的所有内部枚举类型
                       Class<?>[] innerClasses = clazz.getDeclaredClasses();
                       for (Class<?> innerClass : innerClasses) {
                           // 检查枚举类型是否实现了 MyInterface 接口
                           if (innerClass.isEnum() && MyInterface.class.isAssignableFrom(innerClass)) {
                               // 将枚举类型的信息添加到结果列表
                               result.add(innerClass.getName());
                           }
                       }
                   }
               }
           } catch (Exception e) {
               // 处理异常
           }
    
           return result;
       }
    }

参考资料

  • https://cloud.tencent.com/developer/article/1032868
  • https://bbs.huaweicloud.com/blogs/346461
  • https://www.finclip.com/news/f/13948.html

文 | 少个分号 (转载请注明出处)

关注公众号:DDD和微服务

微信号:shaogefenhao

同名知乎:少个分号

本文仅供学习!所有权归属原作者。侵删!文章来源: DDD和微服务 -少个分号 :http://mp.weixin.qq.com/s?__biz=MzA4Mzc2MzcyMQ==&mid=2247484508&idx=1&sn=74fe305a30e0e924a1cabbe96c1d0a5f&chksm=9ff0333aa887ba2c2c5dff913a06088dc840f2fca5d48b9d2e9172a7d4d10cc6b627d2583147&scene=21#wechat_redirect

更多文章:

  1. 从代码到设计的性能优化指南
  2. 为啥不建议用BeanUtils.copyProperties拷贝数据
  3. 全链路压测之影子库及ShardingSphere实现影子库源码剖析
  4. 一次 Redis 事务使用不当引发的生产事故
  5. 系统设计 | 业务编号生成
  6. DDD系列第五讲:聊聊如何避免写流水账代码
  7. 系统设计 | 哪些技术标准可以帮助系统设计?
  8. 系统设计 | 高性价比的测试策略("瓜藤"比喻)
  9. 系统设计 | 微服务权限检查点
  10. 殷浩详解DDD 第四讲:领域层设计规范
标签: 转载 系统设计 数据字典 方案设计
最后更新:2023-10-30

coder

分享干货文章,学习先进经验。

打赏 点赞
< 上一篇
下一篇 >

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复

广告
文章目录
  • 问题分析
  • 方案枚举
  • 参考实现
  • 参考资料
最新 热点 推荐
最新 热点 推荐
视频笔记:微服务架构P4 设计模式:每服务数据库、API 网关和事件驱动架构 干货 | 论Elasticsearch数据建模的重要性 马蜂窝消息总线——面向业务的消息服务设计 基于 MySQL Binlog 实现可配置的异构数据同步 视频笔记:Google发布Agent2Agent协议 视频笔记:什么是微服务,为什么是微服务? 视频笔记:什么是AI 智能体? 视频笔记:什么是Flink?
Elasticsearch 使用误区之六——富文本内容写入前不清洗基于 MySQL Binlog 实现可配置的异构数据同步马蜂窝消息总线——面向业务的消息服务设计视频笔记:微服务架构P4 设计模式:每服务数据库、API 网关和事件驱动架构干货 | 论Elasticsearch数据建模的重要性你可以不用RxJava,但必须得领悟它的思想!如何秒级实现接口间“幂等”补偿:一款轻量级仿幂等数据校正处理辅助工具视频笔记:什么是Flink?
Elasticsearch基础但非常有用的功能之一:别名 3分钟掌握CQS和CQRS架构设计原则 2023 年 AI 盘点(转译) 笔记08 | 搜狗面试题:IO多路复用之select、poll、epoll的区别 6.分层架构(译) Eureka源码之二:服务注册 浅析设计模式2 —— 策略模式 殷浩详解DDD 第四讲:领域层设计规范

CRUD (1) Event Sourcing (1) graphql (1) id (1) NoSQL (1) quarkus (1) rest (1) RocketMQ (2) Spring Boot (1) zk (1) zookeeper (1) 上下文 (1) 事务消息 (1) 二级缓存 (1) 值对象 (1) 关系数据库 (1) 分布式缓存 (1) 原子性 (1) 唯一ID (1) 商品 (1) 多对多 (1) 子域 (1) 字符集 (1) 客户端心跳 (1) 幂等 (2) 干货 (1) 并发 (1) 应用场景 (1) 应用架构图 (1) 康威定律 (2) 异步复制 (1) 微服务架构 (3) 总体方案 (1) 技术方案 (2) 技术架构 (2) 技术架构图 (1) 技能 (1) 持续集成 (1) 支撑域 (1) 故障恢复 (1) 数据架构图 (1) 方案选型 (1) 日记 (1) 服务发现 (1) 服务治理 (1) 服务注册 (2) 机房 (1) 核心域 (1) 泄漏 (1) 洋葱架构 (1) 消息队列 (5) 源码剖析 (1) 灰度发布 (1) 熔断 (1) 生态 (1) 画图工具 (1) 研发团队 (1) 线程 (2) 组织架构 (1) 缓存架构 (1) 编码 (1) 视频 (19) 读写分离 (1) 贵州 (1) 软件设计 (1) 迁移 (1) 通用域 (1) 集群化 (1) 雪花算法 (1) 顺序消息 (1)

推荐链接🔗
  • AI工具集
  • 工具箱🛠️

COPYRIGHT © 2014-2025 verysu.com . ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang

粤ICP备15033072号-2

x