1. 背景

针对数据的 增加、删除、修改 操作，前端在页面进行逻辑操作，直到保存时才去发起请求，将数据传到后台去处理（节省了请求次数和接口的定义量）。

在这种背景下，如何界定入参数据对应的操作类型成为了一个需要考虑的点。设计了几种方案如下，可在不同的场景下参考使用。

2. 方法

  1. public class SourceRule {
  3.     private Long id; // 主键 id
  5.     private Long uid; // 用户 id
  7.     private Integer aaa;
  9.     private Long bbb;
  11.     private Integer ccc; 
  13. }

数据实体例如上所示，根据不同的 uid 可以查找到此账户下的所有记录

2.1 批量删除、批量添加 —— 简单粗暴（适合数据量少的情况，效率一般）

步骤：

  • 直接根据某一特殊的字段，例如用户uid等，删除此字段下的所有数据，然后再把前端请求传来的数据批量插入。

优点：

  • 处理逻辑简单，前后端均不需要做特殊的处理。

缺点：

  • 删除全部记录效率较低，随着数据量的提升，缺点更明显。
  • 两个可变操作，考虑事务问题。

    2.2 ID 判断 —— 后端复杂（效率一般）

    步骤：
  1. 后端对前端传来的数据进行 stream 过滤，分别取出有 ID 和没 ID 的数据集合。
  2. 获取数据库中某用户uid 下的所有数据，拿每一条元素（database）与有 ID 数据集合的每一条元素（request）进行遍历。
    • 交集（两个集合中都有，也可以进一步根据其它字段是否向相同判断是 update 还是 不操作）：修改 | 不操作。
    • 差集（数据库中有，请求参数的集合中没有）：删除。
  3. 没有 ID 的集合直接处理：代表为新增的数据，直接插入表中即可（若考虑唯一索引不能重复的问题，最好先删除，放到最后再添加）。

优点：

  • 操作的数据量较少，一定程度效率略高。

缺点：

  • 后端逻辑复杂。
  • 比对操作需要两层循环，定义有 ID 的数据集合 size 为 m，库中所有与某 uid 相关的数据为 n 时间复杂度为 O(m * n)，效率仍与数据量挂钩明显。

    2.3 ID判断 + 前端局部分类 —— 前后均分难度（效率高）

    步骤：
  1. 前端将逻辑删除的数据存在一个自定义的 deleteDateList 对象中，然后请求时除了表格/列表中的数据外，同样携带这个 deleteDateList 对象。
  2. 后端对前端传来的列表数据进行 stream 过滤，分别取出有 ID 和没 ID 的数据集合。
  3. 处理集合数据：
    • 有 ID：修改 | 不操作
    • 没 ID：新增
    • deleteDateList：删除

优点：

  • 前后端各自做一些处理和判断，难度均分，改动的数据量也少，效率高。

缺点：

  • 双方均需要一定的修改。

    2.4 前端全分类 —— 前端全分类

    步骤：
  1. 前端将逻辑增加、删除、修改的数据，分类存储 addDateList、deleteDateList、updateDateList中，
  2. 后端直接处理集合数据：
    • addDateList：新增
    • deleteDateList：删除
    • updateDateList：修改

优点：

  • 改动的数据量少，后端工作量会简单一些。

缺点：

  • 前端分类处理复杂。