热门标签 | HotTags
当前位置:  开发笔记 > 程序员 > 正文

关于库存表的设计。如果取得当前库存的问题。

关于库存表的设计。如果取得当前库存的问题。一般的进销存的表设计涉及到到订单和仓库表。示意性的大概表结构是这样的:订单表:Order------------------Id
关于库存表的设计。如果取得当前库存的问题。

一般的进销存的表设计涉及到到订单和仓库表。
示意性的大概表结构是这样的:

订单表:Order
------------------
Id  CustomerId OrderDate 。。。

订单明细表:OrderItem
------------------
Id OrderId ProductId Quantity Price  。。。

入库表:InStock
-----------------
Id   stockDate

入库明细表:InStockItem
-----------------
Id InStockId ProductId  Quantity 。。。


(当然还有报损,盘点,丢失,借入借出等表。这里
为了简单起见,不考虑这些)

如果现在要得到某个商品的当前库存,需要汇总此商
品所有入库表的数量-所有订单表的数量,如果数据量
大,这样的计算量是不现实的。

可能考虑加一个如下的库存表

库存表: Repertory
-----------------
ProductId  CurrentQuantity

每次入库和确认销售订单时都对库存表的相应产品数量
进行变更,需要取得某商品的当前库存,直接从库存表
就能得到,但是这个CurrentQuantity字段让我感觉很不
爽,因为关于库存数量,现在就有两笔帐,1.通过汇总入
库数量-汇总订单数量。2.库存表直接记录的当前数量,
一旦两个数对不上,鬼知道是怎么回事儿。人为串改还是
系统故障,上帝都素手无策。

后来我觉得我可以这样设计,增加一个出库变动表。

库存变动表:StockEvent
-----------------
Id EventType EventDate。。。
(EventType可以用来表示订单销售,盘盈盘亏,丢失,借入借出等)

库存变动明细表:StockEventItem
-----------------
Id StockEventId EventId  ProductId  Quantity  CurrentQuantity 。。。
  EventId:用来关联引起库存变动起因表的ID,比如因销售订单造成的出库,
          OutId就关联Order表的Id。
  Quantity:出库数量,对应销售订单的情况,就是订单数量
  CurrentQuantity:当前库存数。


每当有订单销售,盘盈盘亏,丢失,借入借出等时,都相应的增加
StockEvent和StockEventItem表记录,并更新当前库存。

这样感觉模仿了手工记账时代的做法。
好处就是,取得某个商品当前库存时。直接取得该商品最后一条
StockEventItem表记录就可以了,而且每笔库存变动,都有相应的
StockEvent记录。


不知道这样的设计有哪些问题?
谢谢大神指教。

12 个解决方案

#1


库存变动不用记录每笔明细,这属于出库单/入库单的明细信息。

库存日记账(日期,ProductId,采购数,销售数,借入数,借出数,盘点差,……,结余数)主键(日期,ProductId)
用来存放每日的出入库统计,还可以查询某天的库存余额(可以是历史的、还可以是将来预测的)。

至于库存表就是把今天的(ProductId,结余数)同步过来,是为了查询的性能考虑。

#2


引用 1 楼 Tiger_Zhao 的回复:
库存变动不用记录每笔明细,这属于出库单/入库单的明细信息。

库存日记账(日期,ProductId,采购数,销售数,借入数,借出数,盘点差,……,结余数)主键(日期,ProductId)
用来存放每日的出入库统计,还可以查询某天的库存余额(可以是历史的、还可以是将来预测的)。

至于库存表就是把今天的(ProductId,结余数)同步过来,是为了查询的性能考虑。


这个方案是纯照搬手工记账法。
首先日记账的字段(采购数,销售数,借入数,借出数,盘点差)不利于扩展,以后增加新的库存变动
原因(比如借入借出),需要更改表结构,感觉不太好吧。
另外主键(日期,ProductId),是不是考虑日结的方式?类似有个后台程序每天晚上自动运行汇总?
这样不能反映库存的实时变化。

但总体上来说,我们的方案还是相同的。

#3


加一种原因就必须加个业务数据表,这里加个字段算不了什么。

无论做什么业务,必须要有出库单/入库单,执行这个业务的时候 同时更改记账表啊,哪里需要后台程序!
你原先改库存表结余数一个字段,现在只不过同时多改几个字段而已。

#4


引用 3 楼 Tiger_Zhao 的回复:
加一种原因就必须加个业务数据表,这里加个字段算不了什么。

无论做什么业务,必须要有出库单/入库单,执行这个业务的时候 同时更改记账表啊,哪里需要后台程序!
你原先改库存表结余数一个字段,现在只不过同时多改几个字段而已。


如果每笔业务都更新日记账表,我不清楚你为什么要把日期加到主键里去。这有什么意义呢?

另外,你这个日记账的问题,我帖子里说了,就是从日记账里不能追朔到业务表,
比如数据不一致礼,如何验证?这是我这篇帖子的主题问题。

还有,追加个字段不算什么这种想法很危险的。
业务做大了就知道了。要是没有完善的自动化测试,谁能保证不出问题呢?

为什么坚持要照搬手记账模式呢?这种设计有什么优点呢?

#5


每日的(采购数,销售数,借入数,借出数,盘点差,……)可以到不同的业务明细中取验证啊。

你认为随便可以追加个业务的更危险!

如果没有日统计,你验证库存就要 从头算了。

#6


引用 5 楼 Tiger_Zhao 的回复:
每日的(采购数,销售数,借入数,借出数,盘点差,……)可以到不同的业务明细中取验证啊。

你认为随便可以追加个业务的更危险!

如果没有日统计,你验证库存就要 从头算了。


1.你日记账和业务明细表都没有关联,怎么验证?
2.追加业务处理是必须满足的需求,你要考虑怎么以追小的代价满足需求。
   请参考SRP,OCP等设计原则。
3.我设计的StockEvent和StockEventItem表就是为了解决以上问题。你没
   仔细看。而且问题不在点子上。
另外,多动手,会弥补经验不足的问题,比用“!”号表达你的不满更对你有
帮助

#7


把出入库明细再抄一遍——然并卵
你是来提问题还是来秀优越的?
秀优越找错对象了。
我自信做过的(仅库存相关的)系统肯定比你多。

#8


引用 7 楼 Tiger_Zhao 的回复:
把出入库明细再抄一遍——然并卵
你是来提问题还是来秀优越的?
秀优越找错对象了。
我自信做过的(仅库存相关的)系统肯定比你多。



就当顶贴了。

#9


没人感兴趣的问题么

#10


看你们讨论学到不少东西,以下是个人看法,不一定正确,仅供参考。
库存表还是要的,可以大幅提高查询库存时的效率。
库存表中的数量是否实时变动要看系统需要,如果需要实时变动,那么就要,不然可以定时更新库存表商品数量。
加一个日结算表,每日定时结算,可以用来减少对账计算量。
库存变动表可以直接用视图关联实际的业务表。

#11


一方面,要看数据量究竟会有多大了。
我之前写的系统,各种入和各种出会分成很多个表,算库存时,连接数十个表来计算,每个表都有几十万条记录,用不了一两秒就出结果了。
当然,也可以进行简化,对于库存来说,基本上就只有入和出两种了,可以放在两个表中,甚至,可以再简化到一个表中,入为正,出为负,需要计算库存,按料号汇总数量就OK了。看历史库存,过滤一下日期就可以了。
至于入和出的类型,可以用另一个主表来存放,每个操作界面只显示自己对应的类型就可以了。在保存及显示时,根据类型不同显示及操作不同的效果了。

之前曾尝试过,用数十个表分类来存放,用触发器来更新库存表,但一直感觉库存表计算结果可能有错误(这个错误还真没验证过)。

所以,后来就是一直用数十个表存,用一个视图来计算出库存,需要库存时,调用这个视图。数据量不大,还可以。

#12


一个库存表,表示当前库存
然后就是一些单据表,明细表可以了。
加一个出入库表也是可以的,因为出入库不仅仅是采购,销售,还有很多种类型的,所以也可以添加有必要。

推荐阅读
author-avatar
雪影飘枫2502928577
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有