会员系统会员合并逻辑设计疑问

[ztlong]

对于会员系统，存在会员合并的逻辑，可能由于用户手动合并或者系统因为用户补充了部分信息可以判定为同一个会员时就会触发合并。
假设现在系统中有两个会员：
userId1 和 userId2
那么对于其他业务系统，比如订单，微服务方式设计
可能因为历史存在了以下数据：
order1 -> userId1
order2 -> userId1
order3 -> userId2

那么会员系统合并之后，业务系统应该如何操作，现在想到两种操作
1. 逐个去 update 订单归属的会员
2. order 用 in (userId)的方式进行关联

第一种方案对于原始数据进行了操作，繁琐且感觉不一定可靠，业务微服务得监听会员合并事件，如果操作的时候遗漏了就麻烦了
第二种方案需要 其他的业务微服务比如 order 去理解会员合并的逻辑，感觉逻辑不太干净

求问各位还有其他更好的思路吗

[235777178]

新建一张宽表。然后用 userid 进行关联。
原则就是原始数据不要动，必要时候进行追溯

[imn1]

合并后是怎样的数据格式？原来的好像也不见得有问题，想知道合并优化了什么

[GTim]

采用一楼的方法，然后采用延时合并，不要主动帮用户合并，而是用户查了才合并

[ztlong]

@imn1 合并后对于业务系统理解，就是一个会员，原来的主要是涉及到原始数据的 update，第一个是可能怕会漏，另外一个是因为直接刷了原始数据的 userId 字段，这个行为无法撤销。

[ztlong]

@235777178 您是指建宽表关联两个欲合并的 userId，然后查业务的时候用 userId in ()也就是上面说的第二种方式吗？

[235777178]

@ztlong 我不是开发，但是给你的思路是。
用户查了自己的订单信息，系统去宽表里看 userid，如果没有，那就去订单表里查出来订单，合并在宽表中，下次用户再查订单，直接去宽表中查数据。如果有的话，就直接从宽表给客户。

[Rocketer]

新建一个 userid 表，第一列是原始 id，第二列是目标 id，默认情况下两列一样，合并后的就不一样了。

查询时 join 这张表。

[xuanbg]

搞一张会员表，用户表里面加一个会员 ID

[no1xsyzy]

先搞清楚一点：是否可能存在用户手动合并指定错误、或者自动判定基于的信息是错误的情况？
（比如某人自己注册了一个账号，然后通过社工方式合并其他人账号来「盗用其他的人会员资格」）
显然，有合并逻辑时，你不应当破坏原数据，甚至这两个用户不能进行实质合并，而应进行逻辑合并。