AnySQL.net

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

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

ociuldr form=yes ...

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

$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系统来说, 用户数的增长, 业务的增长, 数据量的极速增长, 到一定的量后, 才会发现当初被忽略的细节现在都成了头痛的问题, 成了历史遗留问题, 不满意的用户绝对数量在增加. 在用户的心目中, 事物应当变得越来越完善, 但当发现没有变化时, 变得越来越失望, 为什么当初没造成用户体验问题, 现在却造成了用户体验问题, 当时用得好好的, 什么也没有变, 就变成了问题很多的事物了. 看来对既有事物的完善速度必须要超过社会发展的速度, 才不会引起用户体验问题.

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

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

    上一次只想到了逻辑逻辑层和物理连接层之间的三种关系, 等价(FIRST), 随机(RANDOM), 顺序(FAILOVER). 其实后面一直在思考, 阅读了一些相关文章, 糊思乱想了一通后, 又增加了两种访问方式.

    按位置(POSITION)访问, 指程序提供一个标识位置的数, 然后与逻辑连接层的连接源数目进行取余操作, 根据余数来获取指定位置的数据源. 继续上一次中的四个MySQL的例子, 我们创建如下逻辑连接, 在访问时如果提供的值是5, 则最后取到的是5余4的位置, 即SLAVE1.

LOGICAL.DEFAULT=POSITION|MASTER,SLAVE1,SLAVE2,SLAVE3

    按范围(RANGE)访问, 指程序提供一个标识位置的数, 然后与逻辑连接层的连接数据源进行比较操作, 按顺序找到指定位置的数据源. 继续上一次中的四个MySQL的例子, 我们创建如下逻辑连接, 在访问时如果提供的值是250, 则最后取到的是小于300的位置, 即SLAVE2. 同前面的按位置相比, 这个可以在增减数据源时, 将影响控制得更好.

LOGICAL.DEFAULT=POSITION|MASTER,SLAVE1,SLAVE2,SLAVE3
LOGICAL.DEFAULT.VALUES=100,200,300,400

    在程序中, 可以根据业务特色提供这个标识位置的数, 然后在JDBC的访问URL中提供这个值, 访问代码如下所示.

try {
  Connection db = DriverManager.getConnection("jdbc:anysql:default/250", null);
  ......
  db.close();
}
catch (SQLException sqle)
{
  ......
}

    接下来当然还会思考有没有新的方式了, 有了这些访问方式, 进一步抽像一下, 可以看看能不能将数据库当成一个磁盘(Database as Disk)来看, 写一个弱弱的DatabaseRaid类在实验室玩玩数据冗余.

    上一篇中的逻辑连接层, 通过一个DBLogicalManager类来实现, 并不是标准的JDBC调用方式, 如果要使现有的程序能很快用上这个功能, 要么更改程序, 要么就去实现一个JDBC Driver类, 让程序透明化. 显然第二种方法很好, 于是就写一个AnySQL JDBC Driver类吧.

    JDBC Driver的类名为:

com.lfx.db.AnySQLDriver

    使用这个类时, 需要传入一个保存连接配置信息(逻辑库, 物理库)的文件, 只要创建一个类实例就行了.

new com.lfx.db.AnySQLDriver(Sting config_file);

    接下来就可以用标准的JDBC来获得逻辑库的连接了, URL规则为:

jdbc:anysql:logical_database_name

    比如在批处理中, 要从上一篇的三个Slave库中的一个读取一条记录, 就可以使用如下代码.

try {
  Connection db = DriverManager.getConnection("jdbc:anysql:readdb", null);
  ......
  db.close();
}
catch (SQLException sqle)
{
  ......
}

    现在还没有真正投入使用, 只在实验室中测试了一下, 感觉上还可以.