AnySQL.net

    从应用架构角度出发, 为DataReport增加了逻库连接层后, 为了与物理连接层清晰地分开, 就对原来的数据库连接配置作了改动. 由于这儿并不能算是文档, 就贴个配置范例来说明一下了.

# WebChart元数据库连接名称
ADMINDB=DEFAULT

# 启用的数据库连接
PHYSICAL.DBLIST=ORACLE|MYSQL

# 连接参数设置
PHYSICAL.ORACLE.DBTYPE=oracle
PHYSICAL.ORACLE.DBHOST=localhost:1521:db10g
PHYSICAL.ORACLE.DBUSER=scott
PHYSICAL.ORACLE.DBPASS=8500B089B7B516CE
PHYSICAL.ORACLE.MAXCONNS=4
PHYSICAL.ORACLE.INITCONNS=1
PHYSICAL.ORACLE.LOCALE=ENGLISH

PHYSICAL.MYSQL.DBTYPE=mysql
PHYSICAL.MYSQL.DBHOST=localhost:3306/test
PHYSICAL.MYSQL.DBUSER=
PHYSICAL.MYSQL.DBPASS=1B820063CEA8A955
PHYSICAL.MYSQL.MAXCONNS=4
PHYSICAL.MYSQL.INITCONNS=1
PHYSICAL.MYSQL.LOCALE=ENGLISH

LOGICAL.DBLIST=DEFAULT
LOGICAL.DEFAULT=RANDOM|ORACLE,MYSQL

    这个配置可以让DataReport以Oracle或MySQL为数据源, 如果同时有Oracle及MySQL, 则可以随机从Oracle或MySQL中读取数据展示. 在上一个改进后, 所有的Demo页面都已经改成同时支持Oracle和MySQL了, 你可以重新下载软件包进行更新.

    DataReport的几个演示页面, 有的人喜欢在Oracle上跑, 有的人喜欢在MySQL上跑. 而针对不同的数据源, SQL的写法是不同的, 因此演示页面是和某类数据源绑定的, 给第一次接触DataReport的人带来了一定的困惑.

    不过现在可以为不同的数据源定义不同的SQL了, 如下所示.

WEBCHART.QUERY_1=*

WEBCHART.QUERY_ORACLE_1=select
      to_char(trade_month,'yyyy/mm') month ,
      trade_count count
  from trade_monthly_summary
  where to_char(trade_month,'yyyy')='2008'
 
WEBCHART.QUERY_MYSQL_1=select
      trade_month,
      trade_count+0 as count
  from trade_summary_monthly
  where year(trade_month) = 2008

    将最上层的SQL定义成星号, 这时DataReport会根据数据源的类型, 进行进一步查找, 如果连到Oracle数据库, 就取上面一条SQL语句, 如果连接的是MySQL数据库, 则取下面一条SQL, 进行不同数据源类型的自动匹配, 使得报表定义变得更加灵活.

    做DBA要经常为其他人员查询一些数据, 有些记录的字段数很多, 用SQLPLUS直接出结果时, 很难对得整齐, 因此没有什么用户体验, 会被内部人员投诉, 外部用户的体验关系着企业的业绩, 内部员工的体验关系到工作的满意度.

    Spool的结果的确很乱, 在Yong Huang提议在AnySQL中加入MySQL按列显示功能后, 就在文本导出工具中也加入了这个功能, 第一版本的ociuldr使用如下参数.

ociuldr form=yes ...

    第二版的文本导出工具也有这个功能, 只是SQLULDR2中需要设置三个选项才行.

$sqluldr2 scott/tiger query=emp form=yes
$sqluldr2 scott/tiger query=emp colsep=0x20:0x20 field=0x0a record=0x0a0x0a file=-

EMPNO    : 7369
ENAME    : SMITH
JOB      : CLERK
MGR      : 7902
HIREDATE : 1980-12-17 00:00:00
SAL      : 800
COMM    :
DEPTNO  : 20

EMPNO    : 7499
ENAME    : ALLEN
JOB      : SALESMAN
MGR      : 7698
HIREDATE : 1981-02-20 00:00:00
SAL      : 1600
COMM    : 300
DEPTNO  : 30
......

    能用SQLULDR2来改善用户体验, 真是当初意想不到的事情.

    一直以来, DataReport都是用表格方式显示多行数据, 当我们查询少量字段数很多的记录时, 就不希望以表格方式显示记录, 而希望以Form格式显示, 如下面显示的员工表的信息.

EMPNO	7782
ENAME	CLARK
JOB	MANAGER
MGR	7839
HIREDATE	1981-06-09 00:00:00.0
SAL	2450
COMM
DEPTNO	10
EMPNO	7839
ENAME	KING
JOB	PRESIDENT
MGR
HIREDATE	1981-11-17 00:00:00.0
SAL	5000
COMM
DEPTNO	10

    实现这个功能, 并没有修改任何一行代码, 只是改了一下控制显示格式的XSL文件, 然后在报表定义文件中加入一行.

WEBCHART.XMLATTR=form="yes"
WEBCHART.QUERY_1=SELECT * FROM EMP WHERE DEPTNO=10

    想要更丰富的格式, 只需要再改进一下XSL文件即可, 不需要修改Java代码, 不过这需要你对XML和XSLT比较熟悉.

    首先要承认有历史遗留问题是好事, 因为这一般是在事物新生期被忽略的细节上的问题, 而且往往是因为事物起始时高度关注与追求高速发展, 与解决细节问题之间的时间和资源上的冲突, 就IT系统来讲, 历史遗留问题越多, 表明当初发展的速度越快, 因为一开始资源上也显不足. 先要在心里承认历史遗留问题的正常性, 不出问题时大家都容易理解, 但要是出了问题, 心中不一定能容忍历史遗留问题的客观性.

    除了时间和资源外, 在当时的条件下, 解决新生期的细节上的问题是入不付出的, 并且事物不会因为这个细节上的问题, 而导致当时的失败, 甚至可能什么都表现不出来, 相当长的一段时间内都会隐藏得很好, 除了当时事物的制造者可能知道外, 不是所有的细节上的问题在形成之初就是已知的, 都认为这是一个十分完美的事物.

    虽然不是所有的细节上的问题在形成之初就是已知的, 但有很多应当是已知的, 只是这个细节上的问题, 在传承上出了问题, 事物可能前后经由多个人进行修改与完善, 前面已经感觉到的问题, 如果没有有效地交托给下一个, 就隐藏了, 没被隐藏的一般都是比较大的问题, 不会成为历史遗留问题.

    历史遗留问题的发现一般都是由于事故, 量变引起质变, 在量没有到达之前, 不会形成事故, 不会有让人感觉到难过的严重危害. 拿IT系统来说, 用户数的增长, 业务的增长, 数据量的极速增长, 到一定的量后, 才会发现当初被忽略的细节现在都成了头痛的问题, 成了历史遗留问题, 不满意的用户绝对数量在增加. 在用户的心目中, 事物应当变得越来越完善, 但当发现没有变化时, 变得越来越失望, 为什么当初没造成用户体验问题, 现在却造成了用户体验问题, 当时用得好好的, 什么也没有变, 就变成了问题很多的事物了. 看来对既有事物的完善速度必须要超过社会发展的速度, 才不会引起用户体验问题.

    一个历史遗留问题的爆发, 往往会引出更多的历史遗留问题, 站在今天的时间点回首看去, 会发现一个一个的黑洞, 从而引生出放弃旧事物, 开发新事物的想法, 并且很容易取得一致的共识, 大量的历史遗留问题是很难解决的, 重新做一个要比改造来得更快更好. 另外此时彼时物虽是人已非, 每个人都不想去修复历史遗留问题, 因为长期的积累, 这些问题已经变得很难处理, 处理好了只是个小功劳, 处理不好就是大问题.

    有部份的历史遗留问题一定是通过创建新事物来解决的, 也有一些必须通过修复来解决的, 当你偏向于某一方时, 就会在一定的时间段内引起一定的问题, 问题在于你能否支撑过这段青黄不接的时期.