CDM软件实施注意事项.docVIP

CDM软件实施军规 目录 TOC \o 1-3 \h \z \u 序 1 “十六条”军规 2 第一条：不要使用游标 2 第二条：不要使用SELECT * 2 第三条：一定要按照统一的次序来访问你的表 3 第四条：解决任何需求一定不要改变系统原有库表的主键及库表含义 3 第五条：一定要了解你将要对数据进行的操作，改变索引一定要在事业部备案 3 第六条：无论在单据或者查询中不要打开大的数据集 4 第七条：检索方案中一定不能使用事务 4 第八条：以下存储过程不能修改，修改必须在事业部备案 4 第九条：以下库表不要增加字段，及增加对表的update和delete，修改必须在事业部备案 4 第十条：一定不要在一种业务中自动生成或者处理另外一种业务，尤其是设计到库存或往来的业务。 5 第十一条：检索方案中尽量不要使用临时表，尤其是临时表处理的一个比较大数据量的内容。 5 第十二条：资料初装完成以后一定要进行校验 5 第十三条：在解决需求时使用大数据量的数据库验证你的解决方法是否可行。 6 第十四条：成本核算一定不能随意调整 6 第十五条：一定不要给批号增加结存金额 6 第十六条：一定不要尝试给部门或者人员增加余额账页的管理 6 序 一直以来，用友时空没有就软件技术实施给出明确的操作戒律，各地的技术操作相对自由和随意，也因此产生了不少的隐患和后果，不仅对技术支持，且对项目实施，故，统一规范已是必行之举了，总结出十七条，要求各地技术人员铭记并执行，如因违背十七条所导致的软件问题，事业部将不提供免费帮助，切记！ 这里要说明的是，这十七条不是实施的窍门，也非包治百病的方案，它是基于经验的一次总结关于如何做好一个项目的实施。这些经验来自我们过去几年中经受的教训，一直以来，我们也看到许多同样的错误被一次又一次的重复，这也是此次推出十七条的背景，希望引起各伙伴经理人及技术经理及技服实施人员的广泛重视，并付诸履行，确保每一个项目实施的顺利，保障项目成功，保障服务。 流通与零售行业解决方案事业部 钟小满“十七条”军规 第一条：不要使用游标 如果你想破坏整个系统的性能的话，它们倒是你最有效的首选办法。大多数的初学者都使用游标，而没有意识到它们对性能造成的影响。它们占用内存，还用它们那些不可思议的方式锁定表，另外，它们简直就像蜗牛。而最糟糕的是，它们可以使你的DBA所能做的一切性能优化等于没做。不知你是否知道每执行一次FETCH就等于执行一次SELECT命令？这意味着如果你的游标有10000条记录，它将执行10000次SELECT！如果你使用一组SELECT、UPDATE或者DELETE来完成相应的工作，那将有效率的多。 初学者一般认为使用游标是一种比较熟悉和舒适的编程方式，可很不幸，这会导致糟糕的性能。显然，SQL的总体目的是你要实现什么，而不是怎样实现。 我曾经用T-SQL重写了一个基于游标的存储过程，那个表只有100,000条记录，原来的存储过程用了40分钟才执行完毕，而新的存储过程只用了10秒钟。在这里，我想你应该可以看到一个不称职的程序员究竟在干了什么！！！ 我们可以写一个小程序来取得和处理数据并且更新数据库，这样做有时会更有效。记住：对于循环，T-SQL无能为力。 我再重新提醒一下：使用游标没有好处。除了DBA的工作外，我从来没有看到过使用游标可以有效的完成任何工作。 第二条：不要使用SELECT * 这点不太容易做到，我太了解了，因为我自己就经常这样干。可是，如果在SELECT中指定你所需要的列，那将会带来以下的好处： 1 减少内存耗费和网络的带宽 2 你可以得到更安全的设计 3 给查询优化器机会从索引读取所有需要的列 第三条：一定要按照统一的次序来访问你的表 按照一定的次序来访问你的表。如果你先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。如果你（不经意的）某个存储过程中先锁定表B，再锁定表A，这可能就会导致一个死锁。如果锁定顺序没有被预先详细的设计好，死锁是不太容易被发现的。 第四条：解决任何需求一定不要改变系统原有库表的主键及库表含义 主键是系统设计时一个非常重要的部分，所有的应用都是围绕设定的主键为假设进行开发的，如果我们改变了库表的主键那就意味着我们正在拆毁一栋大楼的承重墙，这个的做法后果是可想而知的，所以警告所有的实施人员一定不要做这样的努力。 改变这种设计基本上有两种接口一是出于客户需求和系统性能，二是纯粹因为懒惰，任何需求都不可能只有一种解决方法，如果因为我们懒惰而改变系统设计，觉得是一种解决客户需求的捷径的话，我想你迟早得为此付出代价，而关于性能的问题，你不需要优化根本就不慢