数值设计表与配置表结合优化问题解决思路

起因

在日常的数值设计及调测工作中,需要将设计表中调整过的数值频繁更新到配置表中,但由于两表的设计目的不一(设计表主要用于根据需要的字段设计数值以及之后的数值调整验证;配置表主要用于字段的数据配置,程序需根据配置表中字段数据读入到游戏中,所以还承担着配置表到配置文件(.csv / .xml / .sql)的输出,因此配置表中的字段最为完整),导致两表实际的设计和操作不同,这就引发了一系列问题。

核心问题

  1. 配置表中的部分字段是设计表所不需要的
  2. 配置表的数据格式规范,而设计表大多散乱(不许过于考虑格式规范化问题)
  3. 设计表调整的数值需要频繁并且快速的反馈到配置表中,快速修改游戏内数值(这需求在项目中后期尤为重要)

解决方案

基于上面的几个问题,在此给出自己的解决方案,为以后的工作指导提供参考,以及达到快速准确的调整数值,减轻工作流程带来的额外负担。

基准

调整配置表字段位置,保证配置表从左到右的字段具有一定的逻辑性

设计表区域划分

区域一:保持设计表里【所需的】字段与配置表完全一致

区域二:用于读取区域一中的单行/多行数据

区域三:用于对区域二的数据进行模拟演算【数值设计核心部分】

区域四:统计区域三中的数据结果,同时加入自己对此的数值预期,通过对比不断调整数值,使结果符合设计预期

可扩展性

1、之后配置表若新增字段,根据逻辑性加入到相应的位置

2、配置表新增字段也是设计表所需要的话,也许根据逻辑性加入到相应位置

注:设计表读取字段应保持弹性

3、设计表有了新增字段,相应的去调整区域三模拟演算部分(公式或者VBA代码)

原文地址:https://www.cnblogs.com/architecture101-gbt/p/8306650.html

时间: 2024-11-14 03:36:15

数值设计表与配置表结合优化问题解决思路的相关文章

【此处有干货~】jmeter+ant+jenkins持续集成配置及过程中问题解决思路

本人是一枚工作近三年的小测试,大学正好专业为软件测试,在工作中用到最多的是功能测试.接口测试.压力测试.偶尔会涉及到性能测试......(小白,很多观念技术跟大佬差距太大,勿喷) 在接口测试过程当中,如果后面需要回归接口,本人采用的是jmeter+ant+jenkins进行自动化构建,在构建失败的情况下,会用过邮箱提醒的方式告知: 强烈给大家推荐一本<全栈性能测试修炼宝典 JMeter实战 pdf >,里面内容很齐全,对于测试本身还是挺有帮助的. 切入正题: 环境配置分为三部分: 第一:jme

我的游戏服务器类库 -- 配置表及其搜索算法

配置表 想必所有的游戏服务器都要用到配置表,配置表可能来自于文件(Excel.XML.JSON等)或者数据库,但为了避免频繁访问磁盘文件或数据库,最终都会在服务器启动时读到内存里.配置表一般由很多行组成,每一行有一个唯一ID.在游戏逻辑中,可以根据ID来查找某项配置.由于每一个游戏服务器都要写类似的逻辑,所以我把它们抽象出来,加到了我的GitHub项目里. 配置项 没有对配置表项做更多的假设,只要求它有一个唯一ID: public interface Config { public int ge

在BPM动态可配置表单中使用NoSQL技术可行性分析——通用流程化应用审批单设计思路(二)

原业务流程平台审批单使用横向表纵向存储的思路,所有流程所使用的业务表单的数据都存在一张物理表中,表中每条数据记录包含Column定义和Value,Column所对应的字段信息,通过定义表来定义.这种做法就是在实现时,需要使用代码进行数据组装,比较繁琐.当表单较大时,界面展现速度慢.此方案查询统计支持有限. 为了满足可配置动态表单的需求,并解决上述方案的不足,采用NoSQL技术来优化设计,因为NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式.按NoSQL的特性,可以灵活进行s

一个配置表优化的想法

今天下班在班车上想了一个关于配置表存储的小优化,起因是早上的时候发现了一个bug,这个bug是由于在运行时动态更改了一个列表配置导致的. 其实关于这种运行时"偷偷"改配置的问题我之前也有考虑过,这种应该是一不小心就会写出的,这不终于都出了一个. 至于如何预防这种问题,我认为在python里面似乎也没有什么好的解决方法,因为它不像c++有const语义,但有一个稍尽人事的预防措施就是把列表型的配置读成元组(tuple).而由此衍生出的一个想法便是:把配置表中所有的列表型配置都读成共享的元

MySQL优化分库分表,为什么要分表,分表以后如何进行排序查询,业务如何设计?

MySQL优化分库分表,为什么要分表,分表以后如何进行排序查询,业务如何设计? 昨天面试新人的时候,遇到了这么一个问题,按照自己的想法大体聊了一些,但大多是感性的,并没有完整的了解why and how. 今天查了一些相关的资料,包括<MySQL性能调优与架构设计>.<高性能Mysql>,慢慢的整体理解,请大家指正. 之一,为什么要分表? 分表,按形式,有水平分表和主附分表.水平分表常见于按ID取模或者按日期将相同表结构的内容散列到不同的表上,主附分表常见于有对应关系的多张表,通过

hive join 优化 --小表join大表

1.小.大表 join 在小表和大表进行join时,将小表放在前边,效率会高,hive会将小表进行缓存. 2.mapjoin 使用mapjoin将小表放入内存,在map端和大表逐一匹配,从而省去reduce. 例子: select /*+MAPJOIN(b)*/ a.a1,a.a2,b.b2 from tablea a JOIN tableb b ON a.a1=b.b1 在0.7版本后,也可以用配置来自动优化 set hive.auto.convert.join=true;

配置文件和配置表定期备份小工具

现在维护的配置文件/表都是人手工备份,上次某机器宕机,想在别的机器上拉起应用,去找备份的时候,发现最近的备份还是去年的,因此有了这个想法写这么一个小工具才进行定期备份.其实细极思恐,每天备份一下还是很有必要的,出事了,也能找到是哪天开始的不是? 设计的思路还是先把哪些机器的文件.哪个数据库的表需要备份,放入数据库中,然后弄一个shell,在某个机器上启动这个shell,使用ftp去备份配置文件,使用exp去dmp数据库文件,完成备份. 首先是数据库设计部分,需要两张表: "机器表":

优化系列 | MySQL Cluster 7.2.7内存表和磁盘表对比测试

一.准备工作自从2009年测试MySQL Cluster 7.0之后,就没怎么关注过它,发展实在太慢了,还有很多不靠谱的地方.前阵子退出7.2.7版本后,看了看新特性介绍,号称性能比以往版本高了很多,于是再关注并进行测试.部署过程不多说,下载PRM包后直接安装即可.共10个节点,其中1个管理节点,其他9个节点同时作为数据和SQL节点,所有节点服务器配置图:MySQL Cluster管理节点关键配置见下: # #ndb config.ini # [TCP DEFAULT] SendBufferMe

【JEECG技术博文】JEECG表单配置-树形表单

表单配置支持树型表单了,具体效果如下图: 配置说明 1.是否树:选择是. 2.树形表单父Id:表的自关联外键. 3.树形表单列表:显示树形图标的列,如上图中为[组织机构名称]. 4.默认值:最外层数据的父Id值,具体看表的设计.上图中在数据库表中的默认值为null.