使用军惠的朋友进来报个到

sunboy001 · 发表于 2005-3-12 21:16

那个windows的服务器，怎么实现850并发用户数，我倒是很感兴趣----啥医院啊，3000多的日门诊量，系统并发用户能达到850？？？

西门吹牛 · 发表于 2005-3-14 17:15

军惠的数据库设计不错，当初设计的时候是301医院信息科的一些牛人建立的，在HIS和数据库领域都是响当当的人物，现在的几套军惠系统的核心还是那套东西，就是增加了一些表，
后来为了打开民用市场，给修改的不成样子了。程序员修改过程在脑子里，人走了，资料没有留下来，后面接的人就明白了80%，再加上自己的修改和思路。如此循环，......

guoge · 发表于 2005-3-15 22:25

西门兄也是pub里的老资格了，平时也是多有拜读你的文章。楼上你的帖子看来是针对我前面的进行的恢复，不知你也是做his的。我特此说明一些。

我想我所说的可能具有一定的局限性，但以我对军卫五年的开发和维护经验有感而发的。我不清楚中国其它his如何，而且我也只能从技术层面讲的。

前段时间使用PL/SQL改写了后台划价程序，花了一个月，其中20天看那段3000行的代码。而我的新的程序代码只有不到1000行，为什么能缩减这么多？我们不讨论现在程序设计的模式，复用，至少我们上学时知道面向过程编程时把公共代码提出写成函数或者过程，可是源代码呢？早在两年前，我向领导提出来重写这段代码，使用oracle的job调度，否则使用现在的版本必须吧后台划价用户名和口令必须配置在参数文件中，存在安全隐患。被否掉了，我终于清楚了，这段代码太难理解，现在除了301的薛主任，恐怕没几个会坐下来去看懂了。

再说一个，门诊收费程序有一个登陆备用服务器的功能，内部程序是两段代码，一段是访问主服务器的代码，一段是访问备用服务器，功能一样，但访问不同服务器都单写代码。其实真正解决方法是使用net8的failover，对用户是透明的，从备份到主服务器的恢复是透明的。我们现在最难改的就是门诊收费程序。每个地方的事件触发错踪复杂。

还要说吗？综合查询的结果总是和科室查询的结果不一样，因为它们查询的数据源根本不同。

我不是否定军卫，但我认为它作为一个时代的产物，必有它的局限性，不必作为圣典来看，作为总设计师的薛主任，他当时设计水平再高，也是有局限性的，毕竟他那是也才30多些。

husthxd · 发表于 2005-3-16 11:37

最初由 guoge 发布
[B]西门兄也是pub里的老资格了，平时也是多有拜读你的文章。楼上你的帖子看来是针对我前面的进行的恢复，不知你也是做his的。我特此说明一些。

我想我所说的可能具有一定的局限性，但以我对军卫五年的开发和维护经验有感而发的。我不清楚中国其它his如何，而且我也只能从技术层面讲的。

前段时间使用PL/SQL改写了后台划价程序，花了一个月，其中20天看那段3000行的代码。而我的新的程序代码只有不到1000行，为什么能缩减这么多？我们不讨论现在程序设计的模式，复用，至少我们上学时知道面向过程编程时把公共代码提出写成函数或者过程，可是源代码呢？早在两年前，我向领导提出来重写这段代码，使用oracle的job调度，否则使用现在的版本必须吧后台划价用户名和口令必须配置在参数文件中，存在安全隐患。被否掉了，我终于清楚了，这段代码太难理解，现在除了301的薛主任，恐怕没几个会坐下来去看懂了。

再说一个，门诊收费程序有一个登陆备用服务器的功能，内部程序是两段代码，一段是访问主服务器的代码，一段是访问备用服务器，功能一样，但访问不同服务器都单写代码。其实真正解决方法是使用net8的failover，对用户是透明的，从备份到主服务器的恢复是透明的。我们现在最难改的就是门诊收费程序。每个地方的事件触发错踪复杂。

还要说吗？综合查询的结果总是和科室查询的结果不一样，因为它们查询的数据源根本不同。

我不是否定军卫，但我认为它作为一个时代的产物，必有它的局限性，不必作为圣典来看，作为总设计师的薛主任，他当时设计水平再高，也是有局限性的，毕竟他那是也才30多些。 [/B]

1.有时候看自己一个月前写的代码都有点看不懂

,就更别说别人了.所以在代码里面一定要写注释,至少要把流程和设计思路写上去.始终坚持:有时候代码就是最好的文档.
2.维护总是一件比较痛苦的事情.特别经历了几年的老系统

3.不管在java世界还是其他地方,都需要坚持频繁的代码重构,改善设计.