军惠系统的优化系列

lfree

另外我觉得天健也许已经改动很大.

lfree

再看看这个:
SELECT MAX (TO_NUMBER (prepayment_rcpt.rcpt_no))
  FROM prepayment_rcpt
WHERE TO_NUMBER (SUBSTR (prepayment_rcpt.rcpt_no, 1, :1)) = :2

真不知道他们如何学习sql的.

SUBSTR (prepayment_rcpt.rcpt_no, 1, :1) 还使用绑定,该使用的地方不用,不该使用的地方乱用.

[ 本帖最后由 lfree 于 2009-7-7 10:04 编辑 ]

HZLZKJ

这么基本的SQL问题我想天健应该可以改正过来吧!

lfree

原帖由 HZLZKJ 于 2009-7-7 13:20 发表
这么基本的SQL问题我想天健应该可以改正过来吧!

天健已经把军惠改了许多,我们使用军惠,但不是天健的.

lfree

原帖由 lfree 于 2009-7-4 18:04 发表
可以发挥一下想象not in 或者 in 这里使用||,这个程序员如果再次遇到的sql,如果要多个字段这样,一定还会用!

过几天在找!

看看这些,程序员的想象力太丰富了.

fals

呵呵，换吧换吧，有啥不能换的，要求把原先的一些功能搬过来就行了。

lfree

原帖由 fals 于 2009-7-7 20:00 发表
呵呵，换吧换吧，有啥不能换的，要求把原先的一些功能搬过来就行了。

这样的话,要看领导了.

lfree

军惠系统的护士站的一个bug,可以导致病人消失或者同床.

就是在换床的时候,执行如下:例子

UPDATE bed_rec
   SET bed_status = '1'
WHERE (ward_code = :1) AND (bed_no = :2)
:1 = '0725'
:2 = 88
----------------------------------
Timestamp: 08:46:42.843
UPDATE bed_rec
   SET bed_status = '0'
WHERE (ward_code = :1) AND (bed_no = :2)
:1 = '0725'
:2 = 25
----------------------------------
Timestamp: 08:46:42.843
UPDATE pats_in_hospital
   SET bed_no = :1
WHERE patient_id = :2
:1 = 88
:2 = '000xxxx'

这个错误很难查,最后一个语句是修改语句,注意它的where条件仅仅是patient_id = :2,限定条件太少!

假设科室A的护士站对25床的病人转科到科室B,科室B的护士站入科到5床.

在科室A的另外一个护士站的界面上25床的病人还存在(在没有刷新床位的情况下),如果这个时候有人入院到25床,她会以为前一个护士对25床没有
处理完,她采取换床操作,将25床的病人移到88床,这样的结果是科室B的5床病人跑到88床.

这样会出现几种情况:
1.如果科室B没有88床,病人消失.
2.如果科室B有88床,并且该床已经有病人,就出现病人同床的情况.

这个问题最主要的是pats_in_hospital的谓词条件.实际上这段代码存在严重逻辑错误,正确的做法应该是:

先修改pats_in_hospital表,并且正确修改后才能修改bed_rec的信息.

UPDATE pats_in_hospital
   SET bed_no = :1
WHERE patient_id = :2 and (ward_code = :3) AND (bed_no = :4)

必须判断成功与否,再执行如下:
UPDATE bed_rec
   SET bed_status = '1'
WHERE (ward_code = :1) AND (bed_no = :2)
:1 = '0725'
:2 = 88
----------------------------------
UPDATE bed_rec
   SET bed_status = '0'
WHERE (ward_code = :1) AND (bed_no = :2)
:1 = '0725'
:2 = 25


我实际感到不能理解的是,这家公司并不是做了一家医院,我无法相信这个错误仅仅存在我们医院.

lfree

这个问题实际上我很早就知道,我仅仅认为这个影响不大,一直没提.
实际上在查询上面这个BUG的时候,我使用logminer查看日志,我发现一个护士站床位刷新的问题,因为在日子里面
我看到大量的update的bed_rec的语句,但是严重干扰了我的分析.

在菜单维护里面有一个"刷新床位一栏卡"的功能.

跟踪可以发现执行如下语句:
UPDATE bed_rec
   SET bed_status = '1'
WHERE EXISTS (
          SELECT pats_in_hospital.patient_id
            FROM pats_in_hospital
           WHERE bed_rec.ward_code = pats_in_hospital.ward_code
             AND bed_rec.bed_no = pats_in_hospital.bed_no
             AND bed_rec.ward_code = :1)
:1 = '0725'
----------------------------------
Timestamp: 09:29:25.453
UPDATE bed_rec
   SET bed_status = '0'
WHERE bed_rec.ward_code = :1
   AND (NOT EXISTS (
           SELECT patient_id
             FROM pats_in_hospital
            WHERE pats_in_hospital.ward_code = bed_rec.ward_code
              AND pats_in_hospital.bed_no = bed_rec.bed_no
              AND bed_rec.ward_code = :2)
       )
:1 = '0725'
:2 = '0725'

我曾经那这段代码问过一个开发人员,按照他的逻辑没有问题.
实际上简单加入一个条件就可以减少大量日志的产生.

UPDATE bed_rec
   SET bed_status = '1'
WHERE EXISTS (
          SELECT pats_in_hospital.patient_id
            FROM pats_in_hospital
           WHERE bed_rec.ward_code = pats_in_hospital.ward_code
             AND bed_rec.bed_no = pats_in_hospital.bed_no
             AND bed_rec.ward_code = :1) and bed_status <>  '1'
:1 = '0725'
----------------------------------
Timestamp: 09:29:25.453
UPDATE bed_rec
   SET bed_status = '0'
WHERE bed_rec.ward_code = :1
   AND (NOT EXISTS (
           SELECT patient_id
             FROM pats_in_hospital
            WHERE pats_in_hospital.ward_code = bed_rec.ward_code
              AND pats_in_hospital.bed_no = bed_rec.bed_no
              AND bed_rec.ward_code = :2) and bed_status <> '0'
       )
:1 = '0725'
:2 = '0725'

我使用logminer扫描一天的日志,如图可以发现,每天护士站要扫描13XX次.
如图:snap9

假设每次update产生日志20K.

20 *1352 /1024 = 26.4M . 我们系统现在一天日志1.5G,
26.4/1500 = .0177 相当于2%的量.

实际上这个问题开发人员是否有优化这个弦,不要动不动就讲我们的代码坚如磐石,不需要修改!

[ 本帖最后由 lfree 于 2009-7-9 09:45 编辑 ]

fals

护士站床位管理的问题，早先的设计思路是假设一个科室只有一个护士站——实际上在那个年代这是普遍现象，几乎没有哪个医院的科室护士站有两台以上工作站的，因此在床位管理方面甚至包括整个病人入出转（ADT）流程中，都没有考虑并发控制的问题。但现在医院规模、信息化应用范围都大大扩展，ADT并发问题就比较突出了。楼上讲的护士站床位管理BUG实际上就是没有进行并发控制导致的。

这个问题处理起来比较麻烦，增加并发控制并不是一两行代码能解决的，实际上涉及到整个业务流程处理机制的优化，据我所知，到现在也没有完全解决掉。

除了ADT的并发控制外，医嘱的并发控制也做得不好。按医疗规范，一个病人不允许两个不同的医生同时对他下医嘱，一个病房的医嘱也不允许有两个不同的护士同时进行转抄，但现在在大型医院医生站、护士站都比较多，实习医生、进修医生也轮换得比较快，医疗管理跟不上的话，医嘱的下达、转抄、校对并发问题也会很突出，虽然出现的概率不高，但因为医嘱是非常重要的信息，任何一次出问题都会扩大化，所以这个问题也是很突出的。

对业务增加并发控制确实是很麻烦的事情，几乎相当于重做一遍，甚至是重新设计整个流程。挺难的。

这也是为什么以小型HIS的基础要扩展成大型HIS非常难的根本原因，对于系统级的并发控制来讲，几乎是不可能在原有的基础上做大范围的扩展。