1、背景
今年开始继续维护之前的数据平台，最近维护是2025年前半年，当时另外还有俩同事。
维护的过程中遇到了数据显示错误的bug，具体来说，就是因业务要求，需要对每一条数据标记归属。默认归属是线下，可以标记为归属线上或者其他地方，我们称之为分库。
2、场景
每个分库都有唯一编码，如何某条数据归属两个分库，用逗号分割分库编码的字符串标记即可。考虑到一个分库编码可能是另一个分库编码的子字符串的情况，数据库用模糊搜索可能会出错，所以要求标记的前后均加逗号。这样，每个分库编码的前后均会有逗号，按分库进行数据库SQL查询时在分库编码前后均加逗号即可。
当然，另一种方案是这个标记只是分库编码用逗号分割的字符串，不以逗号开头，也不以逗号结尾。这样的好处是用逗号拆分时可以避免空字符串，不好的地方是SQL语句模糊查询时，无论在前面加逗号还是后面加逗号还是前后均加逗号，再或者不加逗号，均可能会查询错误。
当时开发时，采用了前后均加逗号的方案。由于维护了7个数据系统，基本上每个开发人员维护一个，所以开发的过程中，对标记的处理逻辑均有差异，而我作为管理人员做了放权。他们离职后，今年由我维护。维护的过程中发现了bug。比较删除标记时，有开发人员只删除了分库编码，导致标记中出现了连续的两个逗号的情况，甚至出现了",null,"的情况。
3、教训
这个事不大，但是做了开发过程中遇到的工作协调方面的问题，有必要记录下来。最终我做了大幅的调整，将前后均加逗号改为前后均不加逗号，只是各分库编码用逗号分割即可。新增、修改、删除编码时的逻辑做了统一处理。这些代码本可以共用，之前采取了放权的方式，得到的教训是：对于有逻辑相通的情况时，只一个人开发即可，不必各自为战。而这种情况有很多，必须提前规划好，这是管理人员或者架构师必须具备的素质。