项目暂时告一段落，下面就工作中的情况以及个人遇到的问题进行一下个人总结：
首先总结一下在项目中学到的东西
1、对游标的使用：在刚刚开始编码的时候，学会了使用游标，开始的时候觉得它对表的遍历很方便，但是在项目中慢慢发现，如果在查询中加入游标，在数据量相对较大时，性能下降很多。所以，对游标的使用应尽量慎重。
2、对函数的创建：在视图中有时会用到一些函数列，函数中的查询不可以查询本身所在的视图，因为这样也会大大降低查询的效率。
3、对float类型的认识：在做项目中，使用了float类型来定义一些列，如：Price，但是发现了很多问题
当值的位数大于6位是float型再转varchar型的时候会变为科学技术法显示
    此时只好将float型转换成numeric型，在转换成varchar
float型变量在存入值时，有时值得大小会发生改变。这个现象发生在对报价保存时，如：保存一个3.8，但到了数据库中变成了3.80001124或3.79998999等
在SqlServer的帮助中是这样描述float类型的：用于表示浮点数字数据的近似数字数据类型。浮点数据为近似值；并非数据类型范围内的所有数据都能精确地表示。
所以在今后的类型定义时，个人认为应避开使用此类型
4、对视图的修改：在项目中发现如果创建好的视图在需要修改时最要使用双击视图后直接写入T-Sql进行修改，如果使用修改视图的话，修改视图中T-Sql有时会发生变化，但是不容易发现。
5、对综合查询视图的使用：在项目中曾建立过功能视图V_Sign_SignInfo，在开始只是觉得方便，但是随着项目的开发，大家都在想这个视图中加入新的列或函数，慢慢的这个视图的查询效率开始降低，随之而来的就是使用到它的查询页面的效率也开始降低，同时几乎所有的页面都存在很多不必要的查询。
6、对并发性的认识：在此次项目的初始测试阶段，主观分打分，投票都出现了十分严重的并发性问题，事务发生死锁牺牲，当时的环境是多人（15人左右）在局域网内对指定的几个表同时进行大量查询操作（有查询有修改），此时事务不可放在上层，因为这样如果上层是循环操作的话会导致上层的事务因未完成而不放弃资源的占用，而下层（SqlServer中）会因为原子操作的完成而让其他事务占用资源，此时的解决办法是：把循环的Update的操作放入一个存储过程。上层的不加入事务，而在存储过程中加入事务，并提高存储过程的事务级别，存储过程中的代码如下：
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
--SET LOCK_TIMEOUT 1800
Begin Tran Tran1
 While(Len(@StrElementID)>0)
  Begin
   Set @CountElement = PatIndex('%,%',@StrElementID)
   Set @TempElement = Left(@StrElementID,@CountElement-1)
   Set @CountPoint = PatIndex('%,%',@StrPoint)
   Set @TempPoint = Left(@StrPoint,@CountPoint-1)
   Update esintypzb.T_Bid_MediSubj set Point = @TempPoint  --更新打分记录
    Where FK_Element_ID = @TempElement and FK_Expert_ID = @FK_Expert_ID and
    FK_Medicine_ID = @FK_Medicine_ID
   Set @StrElementID = Right(@StrElementID,Len(@StrElementID)-@CountElement)
   Set @StrPoint = Right(@StrPoint,Len(@StrPoint)-@CountPoint)
   If @@Error<>0 Goto Error
  End
 Update esintypzb.T_Bid_MediBoundTemp Set SumPoint = @SumPoint Where FK_Expert_ID = @FK_Expert_ID And FK_Medicine_ID = @FK_Medicine_ID
 If @@Error<>0 Goto Error
  Set @Flag = 1
Commit Tran Tran1
Return
Error:
Set @Flag = 0
RollBack Tran Tran1
使用过程表了提高查询效率，减少页面中的多余查询。虽说性能以后了很大的提高，事务不在形成环状的死锁，成线性的队列状态，但在快速频繁的操作中有时还是出现事务报错问题，但是问题发生的概率已降低了很多。
其次总结一下此次的感想
1、想好了在做：这是我参加这次项目中感受最深的事情，接到一个新的任务后不应该马上就动手写，先应完全掌握需求，明确你要实现的是什么，然后考虑如何实现，有必要画一些流程图来帮助，最后才是编码。因为如果提前不想好，而做完之后修改很有可能修改的越来越乱。
2、对于关键点的记录：在编码过程中有时会遇到一些不合法的操作，但为了让用户的整体操作完成，对于这些不合法操作我们做了相应的标示，但是由于工作重心的转移，我们很有可能忘记当时的想法，以至于忽略了对这个关键点存在的问题，最终导致其成为整个项目中的一个死穴。所以，在今后的工作中遇到关键点时，应及时记录，并想出更合理的解决办法，以至于出现的问题不止于流入下一个阶段。
3、对需求的了解和对客户工作方式及内容的了解：在这次项目开发过程中，除了在系统的执行的性能上，在用户的使用上的改动也十分的频繁。开始我们完全归咎于客户的需求不明。但在事后的冷静思考中觉得，其实我们也有原因，我觉得原因在于对用户的需求了解不够透彻，但更重要的是我们对客户的工作方式以及工作的内容的忽视，举例说：我们开始在做对产品的查询的时候是先查生产企业，再查产品，实际上在和用户的交流中，这种查询给他们带来了很大的不便。用户的关注点是先在产品上，然后也许关注一下生产企业。类似的问题还有一些，包括对一些关键数据的处理。如：对包装规格的处理，在看其他代理机构的公市数据发现，他们对于产品包装的处理只有一级（如：1支/盒），对于报价单位的选取也有相应的政策规定，如：此种类产品的包装单位就是支，如果这样处理数据，既简单又安全。所以在今后的工作中我觉得还是应该首先做好的是要深入了解用户需求、工作方式及工作内容（当然在不违法的前提下）
4、对于项目中公市等滚屏处理的地方还有待考虑，虽然此功能的实现是用户的意思，但是，在使用过程中发现，此页面的数据量是十分大的（大多在1500条以上）。这样就加大了客户端对服务器端生成HTML语句翻译的量。在实施过程中有的用户就反映浏览器登陆后十多分钟没有反映。相比较下，其他代理机构的定时翻页就有很多的优点。