如果我想配置某个产品库存为无限的话,值设置为 -1 好吗?
如果我想配置某个产品库存为无限的话,值设置为 -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 那就是无限了
手机话费就是无限库存的
除了 github 上的面试整理文档,还有没有什么高效一点的方式,让我学习学习 有了也踢我一脚 踢我一脚-_- 踢我一脚 困惑中...... 好家伙 好家伙 蹲 …
各位大佬,我想做一些 App ,但不知道做什么,所以问问大家有什么可以做的,征集一下大家的想法要求是:必须是应用市场没有的想法,因为做别人做过的 App 挺没意思的,所以一定要…
这是一段比较有趣的历史,让我们回顾一下笔记本电脑的整个历史吧。可能叫便携式电脑比较好一点。 1970 – 1981 第一个便携式的电脑概念 上世纪70年代,Alan…