一个仓库系统的经历,献给所有的IT人.....

Wms 项目开发经验总结--开发过程零星记录，以备今后整理
（1） 对于小型项目，首先有一个相对稳定的框架，然后采用sql 接合业务逻辑的方式，采用相对公用的底层操作的模式比较快，但是不要忽略一点，就是对于业务逻辑的操作即拼写的sql语句仍然要放到所谓的业务逻辑类里面进行操作，不要放到单独的页面进行处理
这样做的优点，许多代码可以重复利用，方便重载和统一管理，防止数据变更导致的多处修改。
（2） 把对于控件操作数据的模式改为对于数据结构进行操作，比如，我们把获取的数据源绑定到gridview上，我们的数据源是datatable，那么我们所有的业务操作尽量在绑定的dtatable 上进行。而不是通过gridviewrow.row.Cell的方式进行操作，原因是。Net把每个gridview列作为一个独立的对象。如果一个页面存在多个gridview的话，你需要对同一个数据结果进行多个列命名，name的命名。、
（3） 对于不通用的东西，不熟悉的东西尽量少用，尤其在团队开发的时候。
（4） 项目开发的重点在于对业务需求的把握，而每个项目的复杂业务逻辑往往会集中在几点，那么我们需要花时间首先讨论清楚这些复杂的业务逻辑，做出一个相对有效的解决方案。因为这些复杂的业务逻辑往往会涉及对数据结构的大的改动。提早解决会为项目今后的行进打下坚实的基础。
（5） 对于数据结构，我们需要在相对通用的基础上针对项目本身的业务特点进行设计，因为需求始终在变，我们惟有以不变应万变。
（6） 在wms项目开发中，一个最大的数据结构设计的失误在于，对于出库指示编号的理解错误，也就是r3系统发过来的出库指示编号我们需要以此为索引进行出库操作，操作的结果需要再次进入客户的r3系统。我们自己的流水号在这里是不起作用的，除了我们自己用。因此，对于我们主从表bz—bills and bz-billdetail 组合生成出库指示编号的规则我们是无法解决这个问题的，解决方案在bz-billdetail 中增加dsn作为明细表的出库编号。这样即解决了流水号的规则和范围问题。但是最根本的问题，在设计数据结构的时候我们没有搞清楚客户这样倒入指示编号，要用他们的指示编号的意图。
（7） 对于数据库连接的深刻理解，始终保持的连接，和即用即开的原则的权衡。大数据量重复操作与小数据量单此操作的权衡。
（8） 合理的数据结构是整个项目成功的关键。我们要意识到，开发任何程序，目的都是让一个不懂程序的人操作数据，
DB 是数据集合，我们的开发程序是操作集合的工具，工具是否好用反映了开发者对需求的理解、，理解的目的是更好的让数据结构进行反馈、，而反馈的好坏又反映的开发者的关系数据结构的理解，所以一个好的程序需要在每个重要的环节进行把握。而对于如何实现业务逻辑，如何操作数据结构获取结果在整个项目中也很重要，但绝非重点。因此我们可以花更多的时间放在业务需求上，同时基础工作需要及时跟进。业务需求明确以后我们就需要制定一个相对通用，又重点反映业务逻辑的数据结构，我们始终要牢记一点，需求永远都在变化。你的结构支持扩展吗，对于一个大的项目，这点好好重要啊。
（9） 我们的团队是一个好的团队，但是我们的合作仍然不尽如人意，为什么，我们没有把着重点集中处理，而是各自为政，没有虚心的接受别人的看法，这点我们应该像尉经理学习的，任何事情都虚心的接受别人的意见，有意见我们可以保留，但是别人的长处我们要吸取。
（10） 对于系统的dll互相引用问题，由于采用模块化处理，有效地分散了系统的压力，但是出现了不同模块的交叉引用问题，对于开发人员，首先因该清楚各个模块之间的调用关系，业务逻辑模块，系统db层调用的模块，控件封装模块这几个问题都是要开发人员注意的问题。不是用到就调用，否则是会出问题的，导致交叉引用，问题多多，我们以前的几个dll，比如nordasoft.Windows.form.control.dll,shippingxp.control.dll nordasoft.baseclass.dll
（11） BZ_BillDetail 中outquantity=预约数量加实际出库数量 Lockedquantity=预约数量
实际出库数量与状态有关系，比如出菏以后的状态都称为实际出库数量。这时候如果作废出荷以后的出库记录，则需要判断是否是实际出库，对于Lockedquantity需要去背对待，如果是实际出库的话，就需要增加，如果不是，就需要减去
（12） 对于各种敏感时间的纪录，目前是放在操作日志中，这是一个好的方式，操作日志记录了所有的操作过程，根据左联接，就可以获取任何想要得到的时间。
（13） 入库记录的拆分是通过bz—billDetail中的stockindx记录的，一条入库记录可以被拆分成多条，通过orders记录拆分的顺序。
（14） 出库记录的拆分也是通过stockindx记录的，只不过是出库记录的拆分记录的是入库记录的索引，通过记录可以计算入库记录的出库情况。
（15） YM15标注和进度标注，这两个标注是可以有效地促进出库效率，可以让工作人员及时地看到那些事加急，那些是紧急单。
（16） 数据库设计，表示相同意思的一个字段必须是同样的名字，不管在是否在同一张表里。
（17） 数据库设计一定要以一个最基础的数据结构为依托，保证系统的扩展性，因为需求永远在变化。
（18） 对于数据结构的作废状态应该在系统初始设计的时候就敲定，比如把-1作为作废状态。防止在系统后期增加作废状态而在其他视图或者操作中包括的作废状态的记录，而导致计算的结果错误。
（19） 字符串比较是否区分大小写〉〉〉〉
（20） 今天遇到几个实际应用的问题，其实还是与实际业务紧密相关的，而且是事先没有预想到的，对于这种问题，就必须要一个相对通用的数据结构的支持。
（21） 系统并发操作带来的影响一定要事先考虑。
（22） 超时，视图查询和报表打印，以及由超时产生的影响。造成数据重复操作多遍
（23） 仓库中出现系统有库存，实物数目比库存少的情况。
（24） 重复打印出库指示会造成多出实物。
（25） 不要固执的认为效率不是问题，一个系统作的再完美，只要运行慢，就不能说是一个优秀的系统。而一个经过仔细研究的结构恰恰成为制约效率的杀手。
（26） 要多一结构中的多对一，多对多，一对多的关系，在所有的逻辑中都要考虑这个问题，否则他会造成一下难以觉察的潜在危险。
（27） 如何解决结构中的group by 的效率问题
（28） 一定要合理的使用本地缓存，因为它可以有效地改善效率，但是他会给并发操作造成潜在的危险，所以不妨采用动作前的检验，几个字节的访问可以忽略不计的。
（29） 直接拼写sql，对于修改时很方便的，但是如果出现问题也是非常难以查找的，因为每个sql都有可能造成与预期设想的不同，这就造成了开发人员本身的惯性思维，以致很难检测出错误原因，解决方式可以让其他同事帮忙检查。
(30) 数据的刷新在下发过程中需要及时地进行，防止重复下发。验证数据的当前状态必须要跟当前应存在的状态一直。否则需要提示用户。