由入库表和出库表关联

由入库表和出库表关联

您提问中这个想法很有道理，但是必须指出数据库有数据库自己的思想方法！将非数据库的方法，例如将大家常用的EXCEL中的思维带到学习及使用数据库中往往事倍功半，它会导致对数据库的低效率使用，非常不可取。这也是很多数据库初学者常犯的错误。

以库存问题为例，入库增加后库存就必须增加，出库增加则库存就必须减少。在出入库不频繁或数据库用户很少时可以人工手动维护，否则就得以自动化方案来解决了，对于大型数据库系统可以在数据库端利用触发器和存储过程来解决，但是此类手段小型数据库系统ACCESS不支持，只能在应用程序端用编程的方法（这需要解决大量技术问题）来维护库存表的正确性。库存表不管是人工还是自动维护所带来的人力和系统资源开销（包括大型数据库支持的触发器在内）都是非常昂贵的。维护不及时、错误的维护、维护失败和维护规范被绕过等等都会导致“库存"表不正确,其可靠性因而成疑。

其实库存就是入库与出库之差，它是可以通过计算得到的，库存表没必要存在。数据库数据库有一个强大的工具——SQL查询，通过对相关数据表的连接、筛选、分类、汇总加上适当的计算表达式我们可以非常方便地从基础数据表中检索、发掘出直接存在或数据内隐藏的各种各样数据（这要看你的想象力了）。对基础数据计算汇总是数据库的拿手好戏、看家本领，不用白不用！原则上来说，数据库应只保存最基础的数据，除非有特别合理的理由，其他所有通过计算能得到的数据都不应该实际去保存它，需要这些计算能得到的数据时运行SQL查询就好了，这一点对于MSSQL等大型数据库系统也是通用的。它的好处是可以减少数据冗余，更重要的省去了一大堆维护这些数据的繁琐工作和节省大量的数据维护系统开销，而且查询得到的数据是实时的不存在因维护不及时和维护失败而导致的误差。况且除了库存外还有太多的其他计算项目，我们总不能都去保存是吧？因此学会用查询获取有关计算数据而不是实际保存它们后再去获取之才是正确之道。

回到您提问中关于库存的问题上，其实很简单，没必要保存那张”库存“表，只要有入库和出库两张表，加上SQL查询就行了。下面是示例方案：

入库表（物品ID，入库数，进库时间）
出库表（物品ID，出库数，出库时间）
日常出入库按实际发生情况登记到相应的表里就行了

给个库存查询例子，查询每个物品的当前库存余额：
select t.物品ID,sum(t.入库数) as 库存数 from
(select a.物品ID,a.入库数 from 入库表 a
unioan all
select b.物品ID,-1*b.出库数 from 出库表 b)t
group by t.物品ID;

当然学会编写SQL语句并不是一件简单事，但是要学好、用好数据库，SQL语言是必须掌握的。它是数据库里最精华的东西，否则就不要学数据库了。追问谢谢，我先按照您说的研究一下，谢谢您的帮助，顺祝新年快乐，万事如意，财源广进！来自：求助得到的回答

这个最佳答案其实是最差答案，当然他的设计是能实现业务需求的，但是如果这么做的话实现起来会非常复杂。
因为库存并非只有入库和出库，还有盘点的情况。入出库的情况也很多，有生产，销售，采购，损耗，仓库间的调拨，盘点等等。如果用单据明细来计算库存量，那么当增加一种新的影响库存变化的数据时，就需要修改所有的有关库存的表报计算方法，这很可能时无法评估工作量的工作，当业务持续增长后没有人能知道这种变化会影响哪些代码的修改。

另一方面，这种统计的方式虽然看上去很有技术含量，但是从设计角度区看却是非常蠢的。统计所有的单据明细信息汇总库存量会导致sql查询的计算量很大，这样的代码即使写出来也不容易维护。另外你需要保证所有单据的完整才能得到正确的库存信息。
从业务角度来看，库存的量虽然来源于出入库行为，这种行为可以体现为单据。但是实际业务中仓库的出入库都有审核的环节，一旦出入库审批完成后，一般情况下也不会关心具体哪个货是从谁手里出或入的。即使关心这样的细节，最佳答案的设计也不能实现这样的需求。一般业务中都会用批次信息来关联库存和货位信息从而解决这个问题。