论军惠系统使用问题

论军惠系统使用问题

    本单位已经使用军惠系统许多年了，我以前曾写过一篇从性能角度谈论his系统的帖子，
链接如下：[url]http://www.itpub.net/viewthread.php?tid=328735&extra=&page=1[/url]
最近有空，再写一篇关于军惠系统使用方面的文章，从几个方面来讲解这些问题。

    首先在讲以前，我是以本单位使用的军惠系统来讲解，也许存在一些与别的军惠系统不同的
地方，希望大家不要以偏概全。

   1.军惠系统的数据结构讲是非常不错的，毕竟集中了全军医院一些搞信息系统的力量，也许开始
使用的是oracle7.3开发，而且早期的界面做的非常不好看，但是可能还是最实用的。至少我看到的
算是比较好的。

   2. P盘的问题（具体可以看原链接），我个人还是比较同意fals的观点，也许在当时的网络环
境下，使用这种方式来同步数据字典（指应用），从某种意义讲确实大大减轻了数据库以及网络的
负担。但是目前环境已经不同以前，使用这种P盘同步的机制带来了许多问题，有时候用户的P盘会
断开，文件的读写管理等问题，同步等问题。如果要改动输入的方式，改动量很大的，最佳的方式
是改变这种同步的方式，比如通过ftp，http的方式，那些文件有变化在传输到本地。

   3. 绑定变量的问题：关于绑定的问题实际上在许多ORACLE的应用都会有，但是军惠的系统其实
还是很严重的，我个人关于这个问题的看法如果你现在开发的程序还这样，就不应该。毕竟军惠的
系统在很早以前就存在了，但是如果这些问题一直存在而不去完善就不应该。

   4. 性能问题：关于这个问题我听到更多的是对军惠的赞扬，也许其它的许多系统性能更差，当然
这里的功劳也有所谓的P盘。如果仔细看里面的sql语句还是能找出许多有问题的sql语句。实际上军惠
系统写的最差就是物质后勤医疗器械管理模块，里面的sql语句采用的扫描整个表，在运用中使用过筛
的方式执行。如果要改善仅仅通过按照store_id来分区，但是这样仅仅治标不能治本。好在这些表增长
不是很快，我们目前最大的仅仅185M. 我曾听过另外的his厂家讲军惠的问题，他说”军惠系统五年
必down",我问他怎么理解？按照他的讲法军惠的系统五年一定要升级更换硬件升级系统。实际上
确实也是这样（对于我们来讲）。我记得fals讲过，军惠系统有一个将历史记录导入另外表的工具
（或者是程序），也许其它使用军惠有，或者有开发人员来做。

  5.军惠程序有些设置实在不合理，我不知道别的军惠系统是什么样的。拿门诊收费系统来讲，在
用户配置的ini文件中，包含一个窗口号win_no，里面还有几个字段的对应的发票信息。

PREP_RCPT_CURR_NO=1
MED_RCPT_CURR_NO=1118

将这些信息放在ini文件，如果在运行时候死机或者掉电，会导致ini文件没有更新，结果在业务操作中
程序会报ora-00001,主键冲突。另外的问题就是如果更换机器还要把旧机器的配置拷贝回来（当然也可以
访问数据库获得这些信息，来修改ini文件。）这样维护带来许多麻烦！

  6. 取时间问题：军惠系统许多模块取当前时间取的是本地机器的时间，而不是取的服务器的时间，这样
会导致许多同步的问题，也许在早期即使使用像这样的sql语句都会对服务器是一个考验。select sysdate from dual;

  7. 程序界面设计问题，关于这个问题我个人认为军惠系统最严重的，军惠的程序仅仅做好界面，里面的
许多检查根本不做。换一句话讲，军惠系统的界面许多检查根本没有做，或许是因为麻烦，实际上这些编程量还是
挺大的，军惠系统仅仅做了一个框架。作为维护员，我们经常抱怨用户输入错误，实际上许多问题如果在数据库与
界面做好相关检查，许多都是可以避免的。

  8.关于升级问题，我仅仅将我遇到的一些问题：
     1.用户的临时表空间指向一个本地的表空间，升级到10g的时候不行，一定要在升级前先修改
到一个真正的临时表空间。另外要注意的就是要升级管理用户模块的程序。
     2.升级以后执行计划改变的问题，实际上这个问题最大的就是原来的程序没有写order by条件，
升级后执行计划由原来的nest looped改变为hash join。导致输出信息没有按照顺序输出。
     3.字符集问题，军惠的系统开始使用的是US7ASCII，而现在的应用都是使用中文字符集，在升级
我脑子里闪过改变字符集的想法，但是很快就消失，主要是害怕麻烦，要修改用户端的设置以及相关测试。
这个算是给新上系统的一个提示，如果你现在要上军惠系统，一定要开发商选择中文字符集。

  9. 讲了一大堆，应该还有许多，以后想到再写。
  我最想讲一点的就是：如果一个开发团队不思进取的话，迟早会被淘汰的。我看过一些最近上军惠的系统，
从界面看还是原来的老系统，如果军惠一些开发商不去改善军惠系统自身的问题，淘汰也就是时间的问题。

版主，你能分类谈谈各子系统，在运用中的常见问题与解决办法吗？比如门诊收费，住院收费等。万分感激

感谢楼主，让我们了解了不少。。。

P盘的问题---目前天健的版本已经取消了，

我们使用的不是天健版本的军字一号
1.同感
2.P盘问题，确实是个问题，部分新版程序已取消P盘，如果变化，直接从数据库读取
3.没有源代码，我们无法修改
4.5年必down不知道从何说起，我们从99看启用，到现在没有down过，不过曾经作过过期数据转储。
5.这个问题早已解决了，直接从数据库中取值了
6.确实存在
7.确实存在，据说天健在改。
8.1没有升级到10G的打算，稳定第一，而且没有什么特性必需使用10G
8.2我们无法修改
8.3无可奈何了，几百台客户机改字符集可不是一个小工作量

10.补充问题，多用户版本的单用户问题：这个问题实际上很难避免，一些应用或者步骤不能同时进行，最
经典的问题就是护士站转抄的医嘱经常会出现两份，就是护士站使用两台电脑操作。没有相互沟通。实际上
真实的应用这类的问题还不仅仅这些。

今天看到一篇文档，关于天健的介绍：
取消P盘映射
为了降低系统对数据库服务器的压力，“军字一号”2.0版以下的输入法使用网络映射盘技术，将数据库服务器中存放输入法字典的目录映射为客户机本地的P盘，程序运行时以操作本地磁盘的方式直接操作服务器文件，极不安全。同时，由于需要使用网络映射盘方式，医院整个网络只能划分为一个子网，一旦医院网络中有一台机器感染病毒，则全网染毒，存在较大的安全隐患。理论研究和实践均证明，当一个子网内机器超过400台时，网络内广播包急剧增多，网络数据传输压力急剧加大，网络资源浪费较为严重。天健军卫HIS 3.5版取消了P盘映射的方式，输入法字典更新改为客户端程序运行时访问系统输入法配置表来判断是否更新了输入法，当发生更新时，直接从相应的表中重新生成本地输入法字典，这样虽然对oracle数据库增加了一定的访问量，但取消P盘映射，系统可以划分WLAN，服务器和客户机可以划分到不同的网段中，有效地提高了服务器的安全性。同时，划分WLAN减少了同一网段中机器的数据，减少了广播包，也防止了一台机器中毒，全网感染的情况，系统安全性得到较大的改进。

如果你现在要上军惠系统，一定要开发商选择中文字符集。

强烈同意!
不然的话 居然不能用.net  用pb10也有问题 乱码!

不会吧，你修改字符集了吗？

回复 #9 lfree 的帖子

vs2003开发环境下没问题,编译成可执行文件后不行出来是乱码,郁闷得要命!
还有医保系统是中文字符集,呵呵所以搞了两个乱码修复的 .reg.

没错啊，多用户的问题应该各家系统都会存在，就是看多少了！字符集的问题真要下决心解决是可以的，但想想吧，多可怕啊，400-500台电脑，如果有一台漏了，第二天会要命的！

》6. 取时间问题：军惠系统许多模块取当前时间取的是本地机器的时间，而不是取的服务器的时间，这样
》会导致许多同步的问题，也许在早期即使使用像这样的sql语句都会对服务器是一个考验。select sysdate from dual;

今天跟踪了天健的体检程序，天健取了一个巧，在登陆数据库时从服务器取出时间，来更新本地的时间，这样来解决以前的旧问题。
不过进入后用户更改本地时间，问题不是一样。。而且一些windows用户限制了不能更新本地时间(权限问题），这样会报一个错误。
windows 用户必须有power user权限。

写的不错,不过感觉这套东西转地方以后就五花八门,乱七八糟的了

蜗牛背着重重的壳，一步一步往上爬

天健继承了军字一号产品的体系架构和原有的全套代码，进行升级，不断的改进。楼主说的几大问题，全都是军字一号里比较顽固，比较全局性的问题。这中间由于程序员的更换，软件代码规范管理成本过高导致一些细节不到位等诸多问题，到目前为止，只能说解决了很多旧问题，包括一些非常难处理的顽固问题，但随着产品功能进一步细化，客户端程序对数据逻辑控制的增多，HIS产品融合了越来越多的接口，如PACS接口，LIS接口，医保接口等等，不断地产生着新的问题。而为了老用户能平稳升级，特别是老用户的业务数据能平稳地迁移到新版本系统中，天健在设计新功能时，不得不更多地考虑原有设计更改的方便性。所以说，军字一号产品，就犹如蜗牛背着重重的壳，一步一步地往上爬，它在继承了老军字一号优秀的数据库结构设计的同时，也继承了老军字一号代码混乱，界面难看等诸多缺点，只能是一步一步，逐渐地修正。

也曾经考虑过，使用原有的数据结构，重新对系统全部代码进行清理、规划，甚至重新开发。但实际的成本计算下来，非常惊人！企业首先要生存，然后才能谈发展。在当前HIS价位普遍低迷的情况下（天健HIS价格算高的了），要企业投入如此巨大的财力和人力来做这么一件功在后人的事情，估计哪个老板都不愿意干。

终于道出军卫系统的本质问题,有问题不可怕,改就是,哪家公司不是在不停的改呢?改多改少,改得快改得慢的问题而已.

实际上要选择改需要下许多决心。
1.开发人员流失，特别是高素质的人员。
2.许多项目都在运行到，根本没有人来做这个工作。

我了解天健做了许多这方面的工作，实际上我觉得是开发厂商领导的问题，许多到现在还认为军惠有多先进，
我仅仅想提醒这些人不要在报这些观念。

有问题不可怕,改就是

^_^，这么容易吗？
一些问题好改，一些要改动需要下许多决心的。

我曾经写给过开发人员一些要求改进的文档，因为系统要做一次小的升级，但是修改被拒绝。
在他看来程序的逻辑是对的，就没有改动的必要。许多程序员不愿意动已经经过许多考验的代码。

仅仅想快速的完成自己的工作就OK。而且我发现许多程序员都有这种想法。

我个人也接触过许多程序员，我发现他们最大的问题总认为自己是最好的，不肯接受别人的建议，
不肯学习新的东西。

程序员首先考虑的是修改的难度有多大

正在做系统梳理工作

对原有系统的代码进行全面梳理，工作量很大，也很考验开发团队的管理水平，但这个工作正在做，估计一段时间后应该有成果了