军惠系统的优化系列

lfree

函数索引问题2-数据架构的问题
char 与 varchar2 的问题,这个问题并没有出现在军惠,而是我们的电子病历,我费了很大的劲说服对方修改
数据库的表结构,链接如下:
http://www.itpub.net/thread-961107-1-1.html

fals

如题。

当时对Oracle的理解也不够深刻，但我跟踪原版的“军字一号”老版本，也就是军队配发的那个版本，基本上没有见到过不正确使用索引的问题，是不是交给达因公司之后对程序员的编码质量控制上弱了些？

现在新版的系统也比较注意控制这个问题，基本不使用函数索引。

另外，“军字一号”里面组合索引用得比较多，我发现一些医院自己在重建这些组合索引的时候改变了索引列的排列顺序，也在某些情况下导致了性能的下降，楼主也可以查一下是不是有组合索引列排列顺序不合理的地方。


char 和 varchar2的问题，军字一号里基本不使用char型，都是使用varchar2型，即使是定长的字符，也是使用varchar2来存放，比如药品代码

lfree

我仅仅看到的是我们开发公司的军惠，其它的我没有见到。
>现在新版的系统也比较注意控制这个问题，基本不使用函数索引。
这个问题，我觉得仅仅是天健做的好一点吧了。
我看过天健的体检，仅仅几天，里面绑定变量做的很好，sql好象没没有多大问题。

[ 本帖最后由 lfree 于 2009-7-15 08:26 编辑 ]

lfree

如果大家仔细看许多应用的sql语句,最容易出现使用日期函数的就是在日期字段上使用to_char函数.
还有就是trunc函数.

例子:
trunc(column_date) =:1 ...
to_char(column_date,'YYYY-MM-DD') = :1

实际上这些问题都是程序员缺乏必要的培训以及优化知识有关,当然许多也是程序员懒惰造成的.

像第一个例子:
column_date between trunc(:1) between trunc(:1)+86399/86400
column_date between trunc(:1) between trunc(:1+1)-1/86400
如果这样不好看,完全修改如下:
column_date between trunc(:1) between trunc(:1)+0.99999
多写几个9合适呢?东软的医保有些sql就少写一个9
如图(snapc.jpg):


第二个例子:
问题更加严重,如果第1个例子是可能程序员懒惰的话,第二个可以定义为无知:
写成这样很困难吗?
column_date between to_date(:1,'YYYY-MM-DD') and to_date(:1,'YYYY-MM-DD')+0.99999

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

lfree

如果以上第2个例子主要是程序员不了解的话,那么在编程中还会引入另外一个问题,就是函数的参数问题:
还是第2个例子:
to_char(column_date,'YYYY-MM-DD') = :1
如果写成to_char(column_date,'yyyy-mm-dd') = :1这样呢?
如果想使这两条sql使用函数索引,那就必须建立两种风格的函数索引.

再引申看看,如果写成这样呢?
to_char(column_date,'Yyyy-Mm-Dd') = :1

这个问题不展开了.

lfree

其他问题5:
||,like,substr....

我这里仅仅讲像like,如果写成name like '%姓名%',如果结果集合很小,可以写成
select * from t where rowid in (select rowid from t where name like '%姓名%')

如果结果集合很大,这样写执行效率一样很低.

实际上我跟一些开发商讲这些问题的时候,总是讲这个是用户需求,如何在保持两者的平衡.
我的建议就是做一个按钮,要模糊查询的时候选上,因为毕竟大部分知道name的第一个字符是什么.

lfree

过滤式编程6
在军惠系统的后勤系统,大量采用过滤式编程,这样的代码实际上很难优化,仅仅使用分析改善一点点.
这种编程方式一般仅仅适合一些小系统,或者维护一些像科室代码的表,不大适合做大系统.
一旦表变大,运行逐步缓慢.

lfree

在开始实施军惠系统过程中,个人的感觉P盘是一项很不好的设计,维护实在太麻烦了.
那个时候不大了解优化技术,实际上这项设计对减轻数据库的访问还是有一定的作用的.
缺点就是维护的困难,直到现在经常有这个方面的问题.还有目前不知道怎么问题,前台
一台机器配置错误,写反了,出现C盘的文本文件更新服务器的文件.

有机会我接触了天健的体检程序,通过连接数据库后,确定那些文件需要更新,直接从数据库
提取,直接更新本地文件. 再来看看东软,东软好像在门诊收费时,形成2个数组(我猜测的),以后
输入项目时不需要在从数据库提取了.

可惜,这么多年,我们的开发商对于这个P盘还是情有独钟.

展翼

支持这种没有口水的技术贴

lfree

来自军惠之外的问题.
当军惠系统上线以后,电子病历.lis等等许多项目上线,我一直忽视了这方面的优化,
因为有些项目很小,我甚至不知道开发人员什么时候来,做什么?一般这些sql问题都
不大,有性能问题的相对很少,最大的问题就是绑定.
如图:


我觉得太多的程序员缺乏必要的培训,理解绑定并不是很困难,如果知道我想许多程序员
都不会范这种"错误".