一般，在仓库管理的程序中，涉及到进库和出库数据，总是分为进库表，和出库表，然后把仓库名称，供货商，单号等数据另写入一个表，然后用单号吧这两个表关联，这样做当然是为了减少重复数据。
但是我觉得，在一般的小型的仓库管理程序中，用一个表也是可以的。特别是对初学者来说，一个表可以简化程序，特别是对需要查询的数据来说，让程序特别的直观，简单，知道各位高手如何看这个问题。

还是多张表好

以使用感受为标准。

需求决定实现，这是编程唯物论。所谓需求，一是用户使用的要求，二是自己实现的能力，三是维护的要求。整个设计方案，是围绕这三方面综合评定的。用户的要求简单，你的设计也可以简单；但有时设计的简单，给编程和维护带来麻烦，或反过来对用户诸多制约，此时则需变。三个方面现实是动态的，当然，对一锤子买卖来说，不用考虑这些。（关系）数据库设计规范，是实践检验出来的理论，不过那只是原则，需要遵守到哪个程度，由实际决定，但总的来说，给自己留后路，与己方便，与人方便，通常是不错的，留多少后路，自己衡量了。

写死代码，即所谓“硬编码”，是编程第一戒。现在看很多人的代码，死代码占绝大多数，无非是编程方便，跟数据不按性质和用途区分存储和使用是一个思想根源，都是不给自己留后路的，所以他们的程序，用户改一点需求，就要拿源代码改程序，没了源代码，就干瞪眼，总是改程序，于是经常问怎么给程序升级。

所有数据都集中在一张表上，表面看来写程序只用一句查询指令就可以了，很简洁，殊不知那最低效，最耗资源。道理其实很简单，处理一张表的数据，计算机是以记录为单元读写的，哪怕你只读一笔记录的一个字段的值，数据库也要把这条记录的所有数据都提取到内存中，因为那在低级指令中，它是以结构体（struct）的形式读数据的，表的一条记录越长，占的内存就越多、从磁盘中读出来的时间也越长（想想VFP为什么把mem字段的数据分开储存在另一个物理文件就明白了），那相当于一块石子，记录尺寸等于石子的质量，尺寸越大，挥舞起来越费力，但你用一句指令是感受不到的，因为自己没有低级处理数据的经验，才以为源代码的指令越短程序执行越快。事实上，从全部数据中把需要的东西提取出来，即是增加了分拣的工作量，要区分不同性质的记录，反而拖慢了运行速度——你要在查询语句中增加一条区分是进库还出库的识别條件，这就迫使查询代码要把所有记录都过一遍，若是分开，则根本不用考虑这一点。

有道理，受教了。

版主说的有理啊。

倾向于多张表，入库表采集各种物资数据，只保存当前最新的库存信息，可以减轻数据维护、数据查找和修改的压力，出库表只保留出库信息，可以避免混乱。物资由入库表出库时，相关的数据自动转移到出库表中，并做好相应的出库标记，这一过程要自动化是关键，并且要用代码来保证数据转移正确、到位，入库表指定的记录已删除。一个系统的好坏，不在于界面好不好，重要的是代码上的功夫，可以说，代码程序的优化水平、严密程度、容错能力、安全系数与系统最后的易用性、灵活性、稳定性和表现力更为相关。

个人觉得多张表好，也是这样用的。入库表，只是记录入库的流水账。随时可查阅或统计、某段时间进货原始状况。出库表，只是记录出库的流水账，也随时可查阅或统计、某段时间出货原始状况。库存底存表：开始是个空表，但是，以后不空。此表能进一步生成当前库存表。保证当前库存肯定是准确无误的（？怎么做到的），入库账目减掉出库帐目生成的，因为是随时生成的，不是固定表不可能不准。另外，也有很多其他辅助表和功能等等 ...

一张表就直接用EXCEL好了........还用什么FVP哟....乱问乱想