经由Oracle国贸旧同事推荐, 最近开始研究<<推背图>>, 愈看, 心情愈舒畅.
先是预言,马英九将会是台湾最后一个总统.
中国统一以后,日本挑衅,导致其战败, 并从此以后, 一蹶不振, 快哉!
各位同胞,赶紧觉悟,从我们开始,从今天开始打击日货,做有骨气,有正义感的中国人.
看看ChinaRen 校友录里的链接, 有骨气之爱国人士, 后继有人.
“九·一八”国耻日 万人签名纪念
这里是 推背图 的链接:
http://fengwen1103.blogdriver.com/fengwen1103/1107632.html
第四十五象 戊申 （第二次中日战争）
图：两个面向西的武士用长矛指着太阳冲来
谶曰：
有客西来 至东而止
木火金水 洗此大耻
颂曰：
炎运宏开世界同
金乌隐匿白洋中
从此不敢称雄长
兵气全销运已终
金圣叹：「此象于太平之世复见兵戎，当在海洋之上，自此之後，更臻盛世矣。」
解：我猜肯定是美国瞧我们站了它的世界领袖之位，心生嫉妒，挑唆日本争夺钓鱼岛，（也有可能是因为台湾问题，也许第43象同第40象一样，时间跨度很长）引发战争，美日同盟两个打我们一个，但我们最终取得胜利，我们取代美国成为日本的宗主国。（想起我们现在提的和平崛起的理论，简直好笑，我们必须做好军事斗争的准备。）
“有客西来至东而止”，依推背图以前提到的客是指敌人来看，这里的客也是敌人，且是从西往东来。我猜想肯定是美国。我们看图，有两个武士面向西来，（注意是面向西，不是向东）有人说，是中国和某国结盟共同攻击日本，我看未必，没看到这两个人是向西的，一定是美日同盟，指着太阳，是说明他们是为日本而战。这个猜想更为符合实际，因为美日有同盟条约，我们和谁结盟，俄罗斯吗，它会为我们与日美而战，太天真了。所以我们必须做好打一场恶仗的准备。“木火金水”，五行缺土，一定是为了领土之争，最可能的是钓鱼岛了。（有人认为，“木火金水”指的是韩国的国旗，我们同韩国结盟打日本，我觉得几乎不可能，别忘了他们都是美国的非北约盟国，美国驻军占领呢，怎敢和我们结盟，分析推背图要注意结合客观的国际局势和现实发展趋势去研究解读。）“洗此大耻”，联想7勇士日前登岛被捕，真大耻也，别着急，我们早晚要洗的。“炎运宏开世界同”，有可能发展成世界大战，“金乌隐匿白洋中”，金乌，古时对太阳的称呼，如果日本膏药旗，没了太阳，自然成了白旗，说明日本投向了。“从此不敢称雄长，兵气全销运已终”，日本再也不敢有野心了，没了军队（估计连自卫队也没有了），国运从此衰落。（变成中国的附属国？）
Monday, September 17, 2007
Tuesday, September 11, 2007
登陆加拿大两年记
坐在落地玻璃墙的办公室里, 温和的阳光透过窗纱照到脸上, 看着海面跑来跑去的轮船, 有客轮,
大邮轮--从加勒比海到阿拉斯加,经过维多利亚停靠, 还有 集装箱货轮, 时不时有水上飞机跃出水面,迎空而起.
回想起来这两年的生活, 赶上了加拿大的医疗制度,
我自己看过两次医生,一次是2005年冬天 踢足球撞断了脚腕, 在家工作,休息了一个月,
一次是上周被黄蜂(wasp)蜇了,吃了一周抗感染药,好了.
加上看牙医,那就更多了, 6颗门牙花了$7000, 自己只用付$1500,也不用回中国看了.
吃住早就习惯了, 今年夏天, 开始买房子, 根据现在的家庭状况, 可以选择中等的独立屋了,
上天预计我们可以2008年二月拿下, 下一篇帖子再做分解.
说说游玩, 每年出去露营3周, 尽情游览国家/省立/市立公园, 享受着加拿大第三大福利. (老人,小孩福利,暂时靠不上)
其实我是2005年6月30日,从波士顿,沿着美国东北部90号高速公路,到著名的水牛城,
然后北上,在尼加拉瓜瀑布附近,穿过美加边境,踏上了加拿大的土地.
我目标还是比较明确的，父母过来探亲半年, 看看真实的西洋镜.
望着年迈的父母，想想最初的抉择，我们1998年开始准备移民的时候要的不就是这些吗.
设想着回到自己的老家，那个人说历史开始的地方，古老的城墙，妖娆的方言，凉皮，泡馍，酸汤水饺,肉夹馍,拉面,都是我心底一直的牵挂。
十几岁的时候背井离乡，何日是再回去的一天呢？加拿大是个非常好的国家，可它和我们的回去和留下又有多大的关系呢？中国有无数无法解决的难题，可它是我们自己的地方呀！我曾以为也就这样了，在加拿大的蓝天碧水中快乐地老去，不经意的设想回去却勾起这么许多的情绪来。很多的东西哪有那么多道理可讲呢？
回去留下真的就是每个人和每个家庭自己的选择，我不知道那些高深的东西，这里藏龙卧虎的大师太多，可是只要你情愿, 只要你舒服, 只要你愿意选择自己的道路, be passionate and persistent, 哪里的生活都适合你.
明天又是每周三Soccer day, 继续和维多利亚各种高科技公司的足球爱好者较量,包括开发FireFox 的外包公司, 坚持锻炼身体, 健康是革命的本钱.
大邮轮--从加勒比海到阿拉斯加,经过维多利亚停靠, 还有 集装箱货轮, 时不时有水上飞机跃出水面,迎空而起.
回想起来这两年的生活, 赶上了加拿大的医疗制度,
我自己看过两次医生,一次是2005年冬天 踢足球撞断了脚腕, 在家工作,休息了一个月,
一次是上周被黄蜂(wasp)蜇了,吃了一周抗感染药,好了.
加上看牙医,那就更多了, 6颗门牙花了$7000, 自己只用付$1500,也不用回中国看了.
吃住早就习惯了, 今年夏天, 开始买房子, 根据现在的家庭状况, 可以选择中等的独立屋了,
上天预计我们可以2008年二月拿下, 下一篇帖子再做分解.
说说游玩, 每年出去露营3周, 尽情游览国家/省立/市立公园, 享受着加拿大第三大福利. (老人,小孩福利,暂时靠不上)
其实我是2005年6月30日,从波士顿,沿着美国东北部90号高速公路,到著名的水牛城,
然后北上,在尼加拉瓜瀑布附近,穿过美加边境,踏上了加拿大的土地.
我目标还是比较明确的，父母过来探亲半年, 看看真实的西洋镜.
望着年迈的父母，想想最初的抉择，我们1998年开始准备移民的时候要的不就是这些吗.
设想着回到自己的老家，那个人说历史开始的地方，古老的城墙，妖娆的方言，凉皮，泡馍，酸汤水饺,肉夹馍,拉面,都是我心底一直的牵挂。
十几岁的时候背井离乡，何日是再回去的一天呢？加拿大是个非常好的国家，可它和我们的回去和留下又有多大的关系呢？中国有无数无法解决的难题，可它是我们自己的地方呀！我曾以为也就这样了，在加拿大的蓝天碧水中快乐地老去，不经意的设想回去却勾起这么许多的情绪来。很多的东西哪有那么多道理可讲呢？
回去留下真的就是每个人和每个家庭自己的选择，我不知道那些高深的东西，这里藏龙卧虎的大师太多，可是只要你情愿, 只要你舒服, 只要你愿意选择自己的道路, be passionate and persistent, 哪里的生活都适合你.
明天又是每周三Soccer day, 继续和维多利亚各种高科技公司的足球爱好者较量,包括开发FireFox 的外包公司, 坚持锻炼身体, 健康是革命的本钱.
Monday, September 10, 2007
Good practice: Middle-tier DAL or Database API – Database access guideline
The reason I don't use "Best Practice" is that will prevent rest of people create some better new ideas, and let you out the 'Keep an open mind' zone.
So I turned to Good practice:
Middle-tier DAL or Database API – Database access guideline
(Hibernate vs Store procedure)
• Maximise SQL and minimise PL/SQL
• Minimise client code and maximise database server code.
Generally servers are more powerful and built for this type of work. You also want to minimise trips back and forth to the server.
Reference:
Business Logic - PL/SQL Vs Java
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:883929178230
I prefer to put all logic that deals with data in PLSQL. There is no more natural language to interact with SQL data then PLSQL. None.
For example -- native compilation was added -- turned plsql into object code that runs natively on the OS.
Database API, build the data API in the database, you call the data API
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:25405782527721
When to use Hibernate DAL
• One step SQL (SELECT OR UPDATE) to finish your goal
• Heavy and forced interaction in mid tier, like CCBB encryption, that means high coulping too, and hard to encapsulate the process logic.
Jave developer can help us on this list.
When to use Database API and Store Procedure Package
• Complex SQL
For example, book delete check, reference Single Hash Table and list of IDs.
• Many (more than 2) steps data machinations logic in a sigle module
• Reture rows more than one page, let's say 20 rows from database.
We like Database API approach, because it:
1.. make software components modular, I'm totally into modular programming
2.. software modules must carry out a very specific task (and be very efficient at carrying it out)
3.. each software module should be loosly coupled (to limit dependencies)
4.. It removes the need for triggers as all inserts, updates and deletes are wrapped in APIs. Instead of writing triggers you simply add the code into the API. I loath triggers.
5.. It prevents people who don't understand SQL writing stupid queries.
All SQL would be written by PL/SQL developers or DBAs, reducing the likelyhood of dodgy queries.
6.. The underlying structure of the database is hidden from the users, so I can make structural changes without client applications being changed.The API implementation can be altered and tuned without affecting the client application.
7.. The same APIs are available to all applications that access the database. No duplication of effort.
Anything that generates SQL on-the-fly worries me, not just Java. I want to be able to cut and paste the SQL, not try and capture or trace it during a run.
Our concept is "build the data API in the database, you call the data API" .
Database API has been layered by different UI technologies over time.
All about API's. The applications don't do table level(select/insert/update/delete) stuff, the apps don't even really know about tables.
On top of database schema we have an API that does the data stuff.
In the application we call this API but have our own application logic as well
(only application logic is in the application, data logic is – well, right where it belongs – next to the data, waiting for the 'next great programming paradigm to come along')
The fact that our UI is in Java isn't really relevant. You could pretty much see how you would use this package from C#, Java/JSP, Swing, VB, Pro*C, Forms, Powerbuilder, a mobile phone,.
–
Storing application code in the database has had it's champions and detractors.
When you start putting application code in the database, you are in the thoroughly non-portable arena. That code, were you to port your application to another database, would have to be rewritten. But think about your application mid-tier layer, will you port Java code to C#/.Net,-> Pascal -> C -> VB, then to Python, Ruby on Rail ...etc., will you do that?
Its very specificity to that database means it can also take advantage of, and wire close to that engine. There are situations where stored code in the database can be notably faster. Supposed you have to update some chunk of a million rows after doing some machinations on the data.
In a stored procedure the data is read, manipulated, and updated in one step. Meanwhile if you did the same in your middle tier application code, you would have to send that data set over the network, do your manipulations, and send it back. Not only would it make this one task slower, but other transactions vying for that same data could potentially have to wait while that data is in transit, and being manipulated. Also, stored code can serve to encapsulate specific requests which can be invaluable at simplifying your overall application. All three databases support stored procedures and functions. Oracle also supports packages, or collections of stored procedures as well as various object oriented features, which almost no one ever uses. An additional note, a database engine actually context switches between stored code, and the SQL code embedded therein. As since of 9i, Oracle introduced bulk binding, so you can do work on large sets of rows, and update them all in one go, instead of each loop iteration. This feature can even further improve performance quite dramatically.
Document the SQL access database
We'll build a small application for this target, on Oracle APEX (HTML DB).
then QA (and Developer) need to record all the SQL access db in the new developing applications.
* SQL execution path
* SQL performance statistics
So I turned to Good practice:
Middle-tier DAL or Database API – Database access guideline
(Hibernate vs Store procedure)
• Maximise SQL and minimise PL/SQL
• Minimise client code and maximise database server code.
Generally servers are more powerful and built for this type of work. You also want to minimise trips back and forth to the server.
Reference:
Business Logic - PL/SQL Vs Java
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:883929178230
I prefer to put all logic that deals with data in PLSQL. There is no more natural language to interact with SQL data then PLSQL. None.
For example -- native compilation was added -- turned plsql into object code that runs natively on the OS.
Database API, build the data API in the database, you call the data API
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:25405782527721
When to use Hibernate DAL
• One step SQL (SELECT OR UPDATE) to finish your goal
• Heavy and forced interaction in mid tier, like CCBB encryption, that means high coulping too, and hard to encapsulate the process logic.
Jave developer can help us on this list.
When to use Database API and Store Procedure Package
• Complex SQL
For example, book delete check, reference Single Hash Table and list of IDs.
• Many (more than 2) steps data machinations logic in a sigle module
• Reture rows more than one page, let's say 20 rows from database.
We like Database API approach, because it:
1.. make software components modular, I'm totally into modular programming
2.. software modules must carry out a very specific task (and be very efficient at carrying it out)
3.. each software module should be loosly coupled (to limit dependencies)
4.. It removes the need for triggers as all inserts, updates and deletes are wrapped in APIs. Instead of writing triggers you simply add the code into the API. I loath triggers.
5.. It prevents people who don't understand SQL writing stupid queries.
All SQL would be written by PL/SQL developers or DBAs, reducing the likelyhood of dodgy queries.
6.. The underlying structure of the database is hidden from the users, so I can make structural changes without client applications being changed.The API implementation can be altered and tuned without affecting the client application.
7.. The same APIs are available to all applications that access the database. No duplication of effort.
Anything that generates SQL on-the-fly worries me, not just Java. I want to be able to cut and paste the SQL, not try and capture or trace it during a run.
Our concept is "build the data API in the database, you call the data API" .
Database API has been layered by different UI technologies over time.
All about API's. The applications don't do table level(select/insert/update/delete) stuff, the apps don't even really know about tables.
On top of database schema we have an API that does the data stuff.
In the application we call this API but have our own application logic as well
(only application logic is in the application, data logic is – well, right where it belongs – next to the data, waiting for the 'next great programming paradigm to come along')
The fact that our UI is in Java isn't really relevant. You could pretty much see how you would use this package from C#, Java/JSP, Swing, VB, Pro*C, Forms, Powerbuilder, a mobile phone,
–
Storing application code in the database has had it's champions and detractors.
When you start putting application code in the database, you are in the thoroughly non-portable arena. That code, were you to port your application to another database, would have to be rewritten. But think about your application mid-tier layer, will you port Java code to C#/.Net,-> Pascal -> C -> VB, then to Python, Ruby on Rail ...etc., will you do that?
Its very specificity to that database means it can also take advantage of, and wire close to that engine. There are situations where stored code in the database can be notably faster. Supposed you have to update some chunk of a million rows after doing some machinations on the data.
In a stored procedure the data is read, manipulated, and updated in one step. Meanwhile if you did the same in your middle tier application code, you would have to send that data set over the network, do your manipulations, and send it back. Not only would it make this one task slower, but other transactions vying for that same data could potentially have to wait while that data is in transit, and being manipulated. Also, stored code can serve to encapsulate specific requests which can be invaluable at simplifying your overall application. All three databases support stored procedures and functions. Oracle also supports packages, or collections of stored procedures as well as various object oriented features, which almost no one ever uses. An additional note, a database engine actually context switches between stored code, and the SQL code embedded therein. As since of 9i, Oracle introduced bulk binding, so you can do work on large sets of rows, and update them all in one go, instead of each loop iteration. This feature can even further improve performance quite dramatically.
Document the SQL access database
We'll build a small application for this target, on Oracle APEX (HTML DB).
then QA (and Developer) need to record all the SQL access db in the new developing applications.
* SQL execution path
* SQL performance statistics
Sunday, September 09, 2007
Oracle DBA 职业成长计划 本月Victoria IT club讨论主题
Oracle DBA 职业成长计划 -- 本月IT club讨论主题,
主要针对 加拿大BC省 维多利亚 IT同行.
以下是内容简介:
Grow That DBA Career
Square one - How to be an expert.
Salary center:
A typical Database Administrator working in British Columbia -- Victoria earns a median total cash compensation of $96,509, according to our analysis of data reported by corporate HR departments. Half of the people in this job earn between $82,461 and $105,361, from http://salary.monster.ca/
--
Should I Become A DBA?
How do I get my first DBA job?
You’ve landed your first job!
Junior DBA Roadmap
Junior to Intermediate DBA
Intermediate to Senior DBA
--
Attitude and skill set for future
Approach to design database application
Reactive Tuning
Q & A
欢迎各位IT老大(大佬)前来, 有钱的捧个前场, 没钱的捧个人场.
Time: 3:00-5:00pm 15-Sep-2007
Location:
2nd Flr meeting room
Emmanuel Baptist Church (Victoria Evangelical Chinese Bible Church)
2121 Cedar Hill Cross Rd.
就在UVic维多利亚大学南门, 穿过马路西南角.
主要针对 加拿大BC省 维多利亚 IT同行.
以下是内容简介:
Grow That DBA Career
Square one - How to be an expert.
Salary center:
A typical Database Administrator working in British Columbia -- Victoria earns a median total cash compensation of $96,509, according to our analysis of data reported by corporate HR departments. Half of the people in this job earn between $82,461 and $105,361, from http://salary.monster.ca/
--
Should I Become A DBA?
How do I get my first DBA job?
You’ve landed your first job!
Junior DBA Roadmap
Junior to Intermediate DBA
Intermediate to Senior DBA
--
Attitude and skill set for future
Approach to design database application
Reactive Tuning
Q & A
欢迎各位IT老大(大佬)前来, 有钱的捧个前场, 没钱的捧个人场.
Time: 3:00-5:00pm 15-Sep-2007
Location:
2nd Flr meeting room
Emmanuel Baptist Church (Victoria Evangelical Chinese Bible Church)
2121 Cedar Hill Cross Rd.
就在UVic维多利亚大学南门, 穿过马路西南角.
Subscribe to:
Posts (Atom)
Posts
