如果我想配置某个产品库存为无限的话,值设置为 -1 好吗?
我看我们生产环境这样做的,但是我觉得有问题。

这得看具体逻辑吧。

如果超发了,库存变为-1 ,这不得出大问题

2^64 -1

有点作死的感觉

0 超卖就爽翻天了。

普通商品 65535 就够。

分库存类型:有限库存、无限库存,无限库存不做扣减退还操作

只能说设置一个大一点的库存比较好. 具体逻辑也不用改..

whmcs 里面负数就是没货了,可以参考淘宝的商家,设一个很大的数就行了。

没事的,记得退货的时候不要加回去就行了,不然就没得卖了。

确定你不会超卖,就可以

最大的风险可能会是那些正常库存的商品,在某个 bug 触发的情况下被扣成了-1 ,这个时候就爽歪歪了😂

最好是新增一个字段。因为一个字段代表什么含义就应该一直做一样的用处。库存就是个数字。是否无限就是一个 bool 。字段巧用,当时是省事了,以后迭代,交接的维护成本极高。

给个超级大数字会怀孕?

这写-1 的人代码抽象能力估计要告别编码了

实际生活中不可能出现无限库存,所以不需要这个选项

手机充值表示,还是有可能的

给个 1 亿以上的数字不就行了。就和加油站的员工卡一样。起步都是几千万的金额在上面。

null

首先你不应该用 signed 的数值来存储,然后无限的话选择 UINT32_MAX-1 其实就足够了。

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

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

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

给 2 亿不行吗?

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

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

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

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

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

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

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

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

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

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

shopify
缺货后继续销售

math.MaxUint64 这个数够用 N 年了

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

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

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

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

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

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

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

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

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

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

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

我只是单纯从数据设计角度来理解,使用 signed 来存储“数量”这个属性不太合理。如何不 underflow 就是另一个问题了,要考虑如何支持并发,该加锁的地方加锁。

不能存储库存的字段设定特定值。这样会出现很奇怪的业务数据异常问题。

我的做法是:1.加字段标记特殊产品。2. 反正都无限了,库存标记比较大的数值

两种方式都会影响财务模块。所以还需要代码上标记筛选。

不合适,有些时候业务会允许负库存的

不合适,
0.容易触发 bug,
1.不好计数,虽然说是无限量,但是数量还得心里有数

假如接手的不知道-1 表示无限库存,那就完了。可以设置成很大的数,不够再加嘛。

建议设置成数字类型变量的最大值这种

加个标识吧 你没法控制并发下 库存会不会变为-1 如果变了-1 那就是无限了

手机话费就是无限库存的