页面历史记录

1.

...

弹性模型

1.模型的本质是什么？

模型的本质就是 一张表格，可以给他理解为 一张excel 表格，只是不同类型的模型取数据的地方不同，有的来源于数据表，有的来源于json文件，还有的来源于后端逻辑拼接的

2. 标准弹性模型的特点是什么？

数据都来源于  hcm_flex_model_data 这个数据表

通过 model_name 来区分不同的模型数据

3.弹性字段是怎么实现的？

1. 拓展的字段 存在data里面 data为json 字段，  数据库常用的字段有哪些呢 integer类型 string类型，boolean类型，text类型，datatime 类型， json 类型
2. json 类型 是数据库中存的是json字符串 {"a":1,"b":2,"c":"wq"}
3. 既然是json 字符串 理论上来说它是无限大的，可以存储很多数据，实际上它是有限度的，但是这个限度绝对在我们使用范围内，可以放心使用
4. 弹性字段够我们使用，它的缺点也是很明显 也就是效率问题，弹性字段需要从data 里面解析出来，这样就会消耗时间，性能不佳，连表查询尤为缓慢
5. 缓慢的其中一个原因呢是弹性字段不能使用索引

2.性能优化--映射实体字段

1. 哪些模型实现了 实体字段映射呢

1.标准弹性模型

2.EmployeeEducation  教育信息模型

3.TechnicalSkills  技术技能信息模型
4.EmployeeSubSetFlexData 人员信息子集
5.SalaryDataEntry 薪酬明细数据 模型
6.WorkFlowFormDataFlexData 流程数据
7.WorkFlowFormDataChildFlexData 流程子表

2.背景

标准弹性模型 如果数据量比较大， 一些弹性字段使用 过滤，排序，关联等操作速度很慢，性能很差，我们将会把该字段升级到标准字段里面

3.操作

a.

...

修改弹性字段

可以选择一个实体字段，这个实体字段就是即可，一旦选中保存不可修改

b.已有字段 但是没有映射实体字段 ，但是后续需要升级到实体字段

选择字段--->>>点编辑 --->>>修改映射实体字段

选定之后不可修改

调用该接口  /api/升级接口  hcm.db.flex.field.flex.model.update.mapping.entity.field 参数为 {"model_name":"xxxx"}   模型名称

调用该接口的目的是 将已存在的数据进行升级

流程相关的表升级接口为 流程数据表 接口 workflow.mapping.entity.field  传入的参数 为 {"business_id":xxxxx}

例如：wf_form_data_flex_data.10001   business_id 为10001

流程子表升级 接口为 workflow.mapping.entity.field.child 传入的参数为{"business_id":xxxxx，"detail_key":xxxx}

例如 ：wf_form_data_flex_data_child.12#detail     business_id 就是22  detail_key就是detail

4.操作前请思考

1.是不是只要升级了字段 速度就一定会提升呢？

答案是否定的，我们要讲究策略

2.什么样的字段需要升级字段？

首选有关联的，第二选需要过滤的，第三选排序的 ，预制字段有限选前三思

3.多个弹性字段选择映射时是否有策略？

有策略 ，对于弹性模型 data_object_id ，data_object_key1 搭配使用效果最好

好刚用在刀刃上 data_object_id，data_object_id2，data_depart_id，data_object_key1，data_object_key2，data_effect_date

 不要单独使用 data_effect_date

剩下的字段效果不明显

5.快速检查需要配置的字段小妙招

Image Added

3.性能优化--表关联优化策略

背景

list页面速度慢 数据库压力较高 可能造成数据库崩溃/数据库整体性能不佳

...

list 元数据 配置 relation_mode    

注意 前提条件 所有使用到的字段 关联模型是不会去掉的其中包括（过滤/排序/查询字段/做关联）

relation_mode

force_not_used_table

1.强制去掉所有没有使用的表 
2.对于count sql未做特殊处理

least_relation_all

force_not_used_table

relation_mode而定

null

...

1.需要relations内部配置ondemand，不然只去掉type未outer的
2.对于count sql 做了特殊处理去除排序和字段的规则

least_relation_all_root_filter

1.需要relations内部配置ondemand，不然只去掉type未outer的
2.对于count sql 做了特殊处理去除排序和字段的规则
3.根节点权限不过滤

least_relation_all_root_filter_sort

1.需要relations内部配置ondemand，不然只去掉type未outer的
2.对于count sql 做了特殊处理去除排序和字段的规则
3.例如左树的页面 list去掉排序
4.根节点权限不过滤

manual

1.需要relations内部配置ondemand，才会起作用，不然不去掉关联，
2.对于count sql未做特殊处理

ondemand

必须字段

conditions 使用到的字段。 
filter_dict 使用到的字段
fields 查询的字段
sorts 排序的字段