如果我想配置某个产品库存为无限的话，值设置为 -1 好吗？

dangyuluo

2021-10-25 01:41:31 +08:00

@securityCoding 不能这么说，楼主应该是有见过例子的。其实 Linux kernel 里很多函数发生错误的时候返回值都是-1 。

clf

2021-10-25 01:42:53 +08:00

加个字段区分标记无限库存不行吗。

ryd994

2021-10-25 05:31:10 +08:00

@dangyuluo 用 unsigned int 然后 underflow 了那不就成了 uinx max 了吗。这和楼主说的-1 有什么区别

xuanbg

2021-10-25 07:58:45 +08:00

给 2 亿不行吗？

ratel

2021-10-25 08:23:47 +08:00

设置 99999999 最高库存比较好，现实场景中无限库存应该不存在的，一般建议补库存。

nvkou

2021-10-25 08:56:16 +08:00

应该横向派生不同的类，而不是加重内部逻辑

shyrock

2021-10-25 08:57:09 +08:00

你这不是抽象而是篡改业务逻辑。
库存实际上就不可能无限，如果是实体货物，有进货才有库存，成本和仓储空间决定了库存上限；如果是虚拟物品，也有版权费用、人工成本等也会限制库存上限。

你根据实际情况定一个合理的库存，就不会留下奇奇怪怪的逻辑漏洞。

markgor

2021-10-25 09:01:03 +08:00

我之前也试过，后来马上改了；
1 、部分产品允许超售，此时就会出现-1 的情况，无法分辨是超售了还是无限；
2 、设置为 NULL ，业务代码判断的时候需要单独区分判断，可以这样做，但对后续业务代码不友善；
3 、增加栏位，设定为是否不限库存；

最终我们选择的是第三点；
因为产品允许超售|库存|不限；
包括后来增加的功能，部分产品需要二次询价，比方 A 给我们一个基本价，库存 10 ，超出库存的要二次确认，我们有单就飞过去，超出库存部分是否能做由他们决定，这种的话业务上会设置为库存产品|允许超售；
1 、因为业务需要统计还剩多少没卖，所以不能设定为不限库存产品；
2 、由于超出时候不是不能卖，只是流程上需要供应二次确认，所以只能设定为可超售。

所以建议你还是加多个栏位进行判断。
BTW：
我们有些直连对接的分销，业务关系，我们不会反回这种产品究竟是可超 /不可超 /库存数量这些的，一般情况下可超或库存大于 999 的直接返回 999 ；

feitxue

2021-10-25 09:31:46 +08:00

@Reficul 几个月前,百度 app 里面的手机充值,不知什么原因的 bug,冲多少,就送多少话费,一群羊毛党蜂拥而至,不知道被薅了多少羊毛.我还特意冲了 100 去试了一下.

lizuoqiang

2021-10-25 09:33:37 +08:00

咋滴一个无符号 int 43 亿不够你库存了？

nicebird

2021-10-25 09:43:53 +08:00

最好设置一个产品认为用户不会超过的上限，这样能兜底。

H97794

2021-10-25 10:45:22 +08:00

shopify
缺货后继续销售

HUNYXV

2021-10-25 10:50:10 +08:00

math.MaxUint64 这个数够用 N 年了

ospider

2021-10-25 10:59:17 +08:00

参考下业界成熟经验吧，你看王者荣耀 30 级的时候，经验上限是 99999999 （几个 9 忘了……

yuankui

2021-10-25 10:59:45 +08:00

加个类型吧，一个字段显然不够，不够优雅

libook

2021-10-25 11:05:48 +08:00

代码最好完全按照业务逻辑来写，希望合并代码逻辑的话也最好看看是不是业务逻辑上可以合并，有时候不合并比合并的开发、维护、测试成本更低，同时风险也低，还可以不同模块单独分配计算资源，以及单独上线下线。

比如业务上有有限库存和无限库存两种概念，你就写两套，这样故障互相隔离，一部分出 Bug 不会影响另一部分。

等业务和代码比较成熟了，再考虑是否程序规模是否是主要矛盾，是否可以合并一部分来减小规模。

ytmsdy

2021-10-25 11:08:24 +08:00

数据库里统计库存的时候，一般都是直接 sum 一下。想想结果。
生产环境最好不要有负数存在，冷不丁什么时候会拿来运算一下。

pengtdyd

2021-10-25 11:08:44 +08:00

看大家都是从代码的角度分析，我想从业务本身来说：库存顾名思义就是存放在仓库货物的数量，既然是货物的数量就不应该是负数，货物不应该出现凭空消失的状态。

ytll21

2021-10-25 11:32:32 +08:00

@pengtdyd 不能这么绝对，实际业务会有先卖出，后补货的情况。也就是卖多少，补多少。

zjuster

2021-10-25 11:45:11 +08:00

我们的业务兜底逻辑是非正数库存，都视作无库存；

一般是 N 个 9 作为无限库存，或者字段控制（管理库存 /不管理库存，不管理库存=无限库存），我个人觉得字段控制是否管理库存是最合适的，不管理库存的货，代码就可以每天给逻辑库存加一个极大值。

@pengtdyd 销售不看仓库的实物，代码里都是虚拟（销售）库存逻辑，你说的 wms 的实物库存逻辑，两边业务不一样，思路不一样。
就算是 WMS 的实物库存，因为人为操作不规范、繁琐的现象，业务上也存在出现-1 可能性。如果严控的话，可能会影响操作效率。尺度如何控制，要看业务经验了。WMS 毕竟是同时和人和货打交道，人不会完全按照设计操作。