服务端使用了一个public字典 flbhs 存储最大id号。
源码比较复杂，不方便上传，举个例子：
1 订单表，订单编号是PO1234的格式
2 订单表有子表订单发货计划表，发货计划号是 PO1234_DP001，PO1234_DP002
3 订单发货计划表还有子表订单发货计划明细表，编号是在发货计划号上，加上下划线和DT001,如PO1234_DP002_DT001，PO1234_DP002_DT002。
如果对 2 发货计划进行网络编号，PO1234_DP是qz，意味着public变量 flbhs 要存储每个订单对应的键，会有很多键。如果对3编号，则需要存储更多的键。
订单一般每年有1万个左右，对应发货计划也是1万个左右，明细大约在10万个左右。
这只是一部分，系统还有其他的编号也有类似情况，意味着flbhs 里面的键数量是万到百万的量级。
有以下几方面的疑惑:
- flbhs存储在内存中，访问速度很快。如果改用一个表存储，则每次申请号码，系统需要到表中查询数据，取号速度会比较慢？
- flbhs存储在内存中，键数量很大，但相对于内存大小，十万量级，或者百万量级是小还是大？或者说，到什么数量级，需要考虑用表来存储？
- 有没有比表存储更好的思路？
加好友 
发短信
Post By：2021/12/9 8:44:00 [只看该作者]
