NC中间表学习笔记，部分转载

原文： http://blog.sina.com.cn/s/blog_539d361e0100ncgk.html 

数据库设计中，经常遇到一个决策：究竟是使用视图，还是中间表？

         考虑库存管理的一个场景：最普通的单据是入库和出库单，库管员需要看到当前的库存。对库存的处理，我们有两个方案：一是使用视图，所有的入库减去所有的出库，就是当前库存；另外就是使用中间表，建立一个库存表，记录当前的库存。

         1、使用视图的方案

         入库时，系统记录入库单据；

         出库时，系统查询库存视图，判断是否有充足的库存可以出库，然后记录出库单据；

         可见，系统只需要记录入库和出库单据，库存的计算是由DBMS在查询视图时进行的；

          2、使用库存表的方案

         入库时，系统记录入库单据，同时增加相应的库存；

         出库时，系统查询库存表，判断是否有充足的库存可以出库，然后记录出库单据，减少相应的库存；

         可见，系统除了记录入库和出库单据外，还需要更新库存表的当前库存数量；

         3、方案的比较

         对系统本身的设计和编码来说，视图方案易于实现，测试方便；库存表方案则稍微复杂。从这点上看，视图方案可以在原型阶段大展身手。

         用户体验到的性能方面，视图方案的性能压力在查询库存上，库存表方案的性能压力在业务处理上：

         视图方案：由于每次查询库存，DBMS都需要扫描入库和出库单据，查询时间长；还可能会对入库和出库单据加锁，导致入库和出库处理延长，甚至失败（尤其是查询库存视图在一个事务中时）；库存视图如果和其它表或者视图连接，构成复杂的SQL时，由于索引不能有效（或无法）使用，查询速度会更慢；

          库存表方案：库存表上可以建索引，查询速度比视图会快很多；在入库和出库时，更新库存表的SQL会对出入库处理的速度有一些影响，但是由于更新只影响出入库的SKU，与查询库存表并发时，加锁时间非常短，影响会比较小。

         4、结论

         视图方案适用情形：原型，数据量比较小；

         库存表方案适用情形：数据量比较大，针对库存的分析较多；