2010-01-28 Thu
首先要承认有历史遗留问题是好事, 因为这一般是在事物新生期被忽略的细节上的问题, 而且往往是因为事物起始时高度关注与追求高速发展, 与解决细节问题之间的时间和资源上的冲突, 就IT系统来讲, 历史遗留问题越多, 表明当初发展的速度越快, 因为一开始资源上也显不足. 先要在心里承认历史遗留问题的正常性, 不出问题时大家都容易理解, 但要是出了问题, 心中不一定能容忍历史遗留问题的客观性.
除了时间和资源外, 在当时的条件下, 解决新生期的细节上的问题是入不付出的, 并且事物不会因为这个细节上的问题, 而导致当时的失败, 甚至可能什么都表现不出来, 相当长的一段时间内都会隐藏得很好, 除了当时事物的制造者可能知道外, 不是所有的细节上的问题在形成之初就是已知的, 都认为这是一个十分完美的事物.
虽然不是所有的细节上的问题在形成之初就是已知的, 但有很多应当是已知的, 只是这个细节上的问题, 在传承上出了问题, 事物可能前后经由多个人进行修改与完善, 前面已经感觉到的问题, 如果没有有效地交托给下一个, 就隐藏了, 没被隐藏的一般都是比较大的问题, 不会成为历史遗留问题.
历史遗留问题的发现一般都是由于事故, 量变引起质变, 在量没有到达之前, 不会形成事故, 不会有让人感觉到难过的严重危害. 拿IT系统来说, 用户数的增长, 业务的增长, 数据量的极速增长, 到一定的量后, 才会发现当初被忽略的细节现在都成了头痛的问题, 成了历史遗留问题, 不满意的用户绝对数量在增加. 在用户的心目中, 事物应当变得越来越完善, 但当发现没有变化时, 变得越来越失望, 为什么当初没造成用户体验问题, 现在却造成了用户体验问题, 当时用得好好的, 什么也没有变, 就变成了问题很多的事物了. 看来对既有事物的完善速度必须要超过社会发展的速度, 才不会引起用户体验问题.
一个历史遗留问题的爆发, 往往会引出更多的历史遗留问题, 站在今天的时间点回首看去, 会发现一个一个的黑洞, 从而引生出放弃旧事物, 开发新事物的想法, 并且很容易取得一致的共识, 大量的历史遗留问题是很难解决的, 重新做一个要比改造来得更快更好. 另外此时彼时物虽是人已非, 每个人都不想去修复历史遗留问题, 因为长期的积累, 这些问题已经变得很难处理, 处理好了只是个小功劳, 处理不好就是大问题.
有部份的历史遗留问题一定是通过创建新事物来解决的, 也有一些必须通过修复来解决的, 当你偏向于某一方时, 就会在一定的时间段内引起一定的问题, 问题在于你能否支撑过这段青黄不接的时期.
Relative Posts:
）
2010-01-27 Wed
Author: AnySQL, published on dbatools.net, Oracle Data Recovery, Tools, WebChart Report, etc.
Usually our application are bound to one physical database, for example, we always read our data from specific Oracle database or MySQL database, or write business data to specific Oracle database or MySQL database. The physical database is not transparent to the application, many application developers know which physical database the data stores. But that's not so good, we'd better introduce a logical database layer between application and the pnysical database.
We create some logical database name, and in the application code, we just use the logical database name, then we can intoduce a relation map between the logical database name and physical database, while the appliction doesn't care about the physical database location.
LOGICAL.logical database name=relation type|data source list
In the WebChart utility, I intorudced 5 types of logical relation between the application and physical database, we may call it logical relation. The first type is equal (FIRST), always choose the first data source.
LOGICAL.WRITEDB=FIRST|masterdb
The second type is random (RANDOM), choose one data source from the data source list randomly.
LOGICAL.SLAVEDB=RANDOM|slavedb1, slavedb2, slavedb3
The third type is sequential (FAILOVER), if the first is unavailable (markdown), then get the next data source. We want our application read data from slave first, if no slave available then read data from master database.
LOGICAL.READDB=FAILOVER|slavedb, writedb
The forth type is get data source by position value, the application will get the data source by a specific hash value, and we get the data source by mod it with available data source count. If we provide a hash value 5, then we will get the get the slavedfb3 connection (5%3=2).
LOGICAL.SLAVEDB=POSITION|slavedb1, slavedb2, slavedb3
The last type is get data source by a range value, the application will get the data source by a value range. If we provide a range value 150, we will get slavedb2 connection.
LOGICAL.SLAVEDB=RANGE|slavedb1, slavedb2, slavedb3
LOGICAL.SLAVEDB.VALUES=100,200,300
I found it may be valuable to make the application transparent to the physical databases. How do you think about it?
Related Posts
Twitter Me? | Leave New Comment(Current: 1)
Link: http://www.dbatools.net/experience/logical-database-access-layer.html
Author: AnySQL, published on dbatools.net, Oracle Data Recovery, Tools, WebChart Report, etc.
It has been 5 years since I released the first version of AUL utility, and I have helped lots of customers to get their data back from corrupted database, such as lost system tablespace, table dropped or truncated. But every time AUL started, you were required to input a new license code, which I called it "dynamic license model", it becomes obsolete now.
On windows platform, AUL will not change the register code unless you restall the windows, or move it to another host. So you can buy one real AUL license to recover your data at any time, for any Oracle databased. The fixed license model is comming for you.
For example, every time I start the AUL utility, it will generate the same register code.
Register Code: DETO-NODT-JETT-DNMX-DDCN
AUL : AnySQL UnLoader(MyDUL) for Oracle 8/8i/9i/10g/11g, release 5.1.1
(C) Copyright Lou Fangxin 2005-2010 (AnySQL.net), all rights reserved.
AUL>
AUL does not bind it to a physical host, it may change the register code after you reinstall or upgrade the windows version, or replace the disks etc. The newer fixed license mode will give more benifit to AUL customers.
After all, now you can get a real AUL license, not just a service.
Related Posts
Twitter Me? | Leave New Comment(Current: 0)
Link: http://www.dbatools.net/mydul/fixed-aul-license-is-available.html
因为我们国家正在酝酿出台《反虐待动物法》，一条关于违法食用或销售猫狗肉者最高可被罚款五千元并被拘留15天的专家建议在社会上引发巨大反响。我对这样的新闻和争议，通常都不会作任何评论，原因很简单，它仅仅只是一些人的看法，尚未成为法律，也没有成为一种“事件”，而且根据我的法律知识，这个规定压根就不可能成为法律条文，其次是，媒体在报道这些东西的时候，都有炒作夸大的成分，譬如说所谓的“专家建议”，在吃狗肉的问题上，我们国家哪有什么专家呢？有，也应该是那些厨师啊。我今天之所以想说几句，实在是因为我非常喜欢吃狗肉，无论是江苏的沛县狗肉，还是湖南的烟熏腊狗肉，都是我的至爱。而在我们国家，也确实有人因为喜欢狗，时常做出一些让人觉得非常过分的事情。譬如，有一次，在电视里看到一个新闻，说一帮爱狗分子埋伏在公路边，硬是把一辆私人卡车拦了下来，车上装有很多狗，车主准备运往广东的某些饭店。爱狗分子仗着人多势众，不顾车主的极力反抗，打开车门，把车上的狗全给放了跑了，没有给人家分文补偿。可怜的车主急得只好边哭边跺脚，仿佛遇到了一帮神经病。
习俗，或说习惯，是法律的一个重要渊源。中国人历来是有吃狗肉的习惯的，否则也就不会有名扬四海的沛县狗肉。因为有这样的历史和习惯，所以，历代中国都没有禁止吃狗肉的法律，相反，还把狗肉当作美食的一种。那么，为什么现在有人要禁止吃狗肉呢？收集一下网络上的意见，大致有这么几点：一，外国人不吃；二，狗是人类的好朋友；三，杀狗特别残忍；四，现在有很多人把狗当作宠物在养，他们对狗的感情很深。然而，细究起来，这些理由都是靠不住的，都不足以用立法来予以解决。外国人不吃，中国人就吃不得？外国人不但不吃狗，据说还不大喜欢吃动物内脏，比如鸡肝，猪肝，甚至连猪头都不大吃，莫非我们也要禁止一下呢？狗是人类的朋友，猪、牛、鸡，难道就不是？杀狗残忍，杀猪就不残忍？
外国人，主要是西方人，之所以不大喜欢吃狗肉，一个重要的原因是，西方民族是游牧民族，狗和马一样，可以用来打猎，是生产工具。打猎，打的当然也是动物，如果没有狗，他们就吃不到其他动物。而在我们中国，特别是汉族，是农耕民族，狗的作用不大，相反，却很看重牛的作用，所以，我们中国人，汉人，是不大会杀牛吃牛肉的，一条牛死了，都很痛苦。因为不大吃牛肉，所以，汉人烹饪牛肉的水平也就一直不高，没有外国人那么会吃。外国人不一样，他们的牛是不需要劳动的，养大了，就是用来杀掉吃的。所以，好多事情都是有原由的，一个民族吃什么，不吃什么，自有他的道理。
而在道理之外，惟一可以理解的，就是有人因为喜欢狗，把狗当宠物养，对狗有着很深的感情，所以，他们看不得别人吃狗。但是，这就像有人同样看不得他人养狗一样，纯粹属于个人爱好，而不是众意。没有众意的支持，如何去立法呢？
更何况，在当下中国，那些把狗当宠物养的爱狗分子，大多都是比较有钱的，我们不要忘了，还有很多人，像我，连饭都吃不饱，更不要说养狗了。在这寒冷的冬季，出于本能，他们只会哆嗦着去想，如果现在能有一碗热腾腾的狗肉煲，那该多好啊。
昨天Michelle给我团的棉衣也到货了，买给家人的，真是辛苦刘大人了，给她肯定是很多麻烦了。
感谢感谢！
2010-01-26 Tue
上一次只想到了逻辑逻辑层和物理连接层之间的三种关系, 等价(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类在实验室玩玩数据冗余.
