SQL

Head First Design Patterns

SQL — 2006-05-10 14:26:00Z

--选择自 calvinxiu 的 Blog

    在更大的计划之前，先温习一下Design Pattern的功课。
    看了《Head First Design Patterns》里讲Decorator的样章，发现JOLT大奖不是白拿的，叙事能力之强，表达之清晰，不是那些满腹经伦的老先生可以比的。而且整个Pattern的讲述过程循序渐进，真的可以保证--小白都能学会设计模式。
    可惜就只有样章。Head First系列的电子书都不好找，只好还是翻出老先生们的书来看。
    这次温习很快做完，其实GOF80%的模式，都是基于一个原则：

优先使用对象组合,而不是类继承.

    初学OO的人，都习惯用现实世界去映射程序世界，继承是最自然的思路。GOF其实就是在扭转这个思路，让大家习惯使用组合，委托和程序对象。

     组合机制只要根据两大原则，就可以变化出绝大部分的GOF模式.
     1.任何耦合都可以通过增加一个中间层来解耦
      代表模式有:   Facade , Mediator , Adapter 和 Factory/Abstract Factory , Proxy

     2.通过组合来扩充对象特性,可以避免纯继承引起的类爆炸
      代表模式有: Bridge , Decorator , Chain of Response , Strategy/Command

3.另外还有些独立的常用模式如Singleton , Visitor , Observe

写给自己看的重放慢镜:
1.Facade : 为了减低一个系统和另一个系统的内部类之间的耦合性。建立对象Ａ代理系统的主要功能

2.Mediator:为了减低两个对象之间的耦合性。建立一个中间对象C，同时具有A和B的实例,并把C赋给A和B

3.Adapter: 为了匹配不同的对象使用同一接口。建立对象B,代理A的方法并使其接口匹配。

4.factory: 为了不依赖于具体对象而依赖于接口的创建对象。程序通过Factory获得对象。

5.Proxy: 除了不依赖于具体对象，还能在过程中插入动作．程序通过Proxy调用对象的方法(AOP)

6.Bridge: 如果对象特征向两个方向发展，Bridge能够避免两组对象特征的排列组合引起类爆炸。一组特征如大杯、中杯，一组特征如加奶、加糖。把其中一组特征抽象分离为接口2，把接口2的实例传入到主继承树中。

7.Decorator: 通过包裹原对象，为原对象的动作添加新的动作。新类继承于原类，有原类同样的方法和原类的实体调用新类的方法时，会调用原类实体的原方法，再加上新类对其的扩展。

8.COR: 通过安排职责链，让各对象根据情况添加自己的动作。每个对象都有下一个对象的指针，根据情况完成自己的操作后，把控制传给下一位。Apahce Jarkarta Commands有chains库。

9.Strategy/Command: Template模式的对立物，把动作封装为对象进行组合。

10.Observe: 通过一套机制，监控Observebal对象的状态变化。JDK实现了两套接口进行辅助。

11.Visitor: 通过一套机制，让独立对象遍历组合里的所有对象，执行共同的动作。被访问对象有个accept(访问者)函数，在函数里面调用访问者.访问(this)，不算很优雅的一个模式。

作者Blog：http://blog.csdn.net/calvinxiu/

长时间没有光顾，如今也应该写点东西了：）

SQL — 2006-02-24 08:56:00Z

可是，写点什么呢？

Sybase ASE12.5全局变量 by hobbylu

SQL — 2005-05-25 17:10:00Z

@@authmech
,@@monitors_active
,@@version_number
,@@msgschema
,@@msgreplytoinfo
,@@msgstatusinfo
,@@msgstatus
,@@msgid
,@@msgtimestamp
,@@msgproperties
,@@msgheader
,@@recovery_state
,@@max_precision
,@@lock_timeout
,@@datefirst
,@@tempdbid
,@@bootcount
,@@boottime
,@@bulkarraysize
,@@bulkbatchsize
,@@stringsize
,@@invalidsuid
,@@maxspid
,@@minspid
,@@version_as_integer
,@@unicharsize
,@@min_poolsize
,@@heapmemsize
,@@maxpagesize
,@@invaliduserid
,@@guestuserid
,@@probesuid
,@@maxgroupid
,@@mingroupid
,@@maxuserid
,@@minuserid
,@@maxsuid
,@@minsuid
,@@ha_local_nodeid
,@@crthaproxy
,@@errorlog
,@@haconnection
,@@failedoverconn
,@@hacmpservername
,@@cmpstate
,@@remotestate
,@@localstate
,@@nodeid
,@@curloid
,@@textptr_parameters
,@@transactional_rpc
,@@cis_rpc_handling
,@@cis_version
,@@scan_parallel_degree
,@@parallel_degree
,@@textcolid
,@@textdbid
,@@textobjid
,@@textts
,@@textptr
,@@identity
,@@mempool_addr
,@@shmem_flags
,@@kernel_size
,@@kernel_addr
,@@transtate
,@@char_convert
,@@maxcharlen
,@@client_csexpansion
,@@client_csname
,@@client_csid
,@@ncharsize
,@@thresh_hysteresis
,@@pagesize
,@@langid
,@@language
,@@servername
,@@isolation
,@@tranchained
,@@textsize
,@@spid
,@@max_connections
,@@dbts
,@@timeticks
,@@options
,@@total_errors
,@@total_write
,@@total_read
,@@packet_errors
,@@connections
,@@pack_sent
,@@pack_received
,@@idle
,@@io_busy
,@@cpu_busy
,@@version
,@@trancount
,@@nestlevel
,@@procid
,@@rowcount
,@@error
,@@sqlstatus
@@authmech
@@bootcount
@@boottime
@@bulkarraysize
@@bulkbatchsize
@@char_convert
@@cis_rpc_handling
@@cis_version
@@client_csexpansion
@@client_csid
@@client_csname
@@cmpstate
@@connections
@@cpu_busy
@@curloid
@@datefirst
@@dbts
@@error
@@errorlog
@@failedoverconn
@@guestuserid
@@hacmpservername
@@haconnection
@@heapmemsize
@@identity
@@idle
@@invaliduserid
@@io_busy
@@isolation
@@kernel_addr
@@kernel_size
@@langid
@@language
@@lock_timeout
@@maxcharlen
@@maxgroupid
@@maxpagesize
@@maxspid
@@maxsuid
@@maxuserid
@@max_connections
@@max_precision
@@mempool_addr
@@mingroupid
@@minspid
@@minsuid
@@minuserid
@@min_poolsize
@@monitors_active
@@ncharsize
@@nestlevel
@@nodeid
@@options
@@packet_errors
@@pack_received
@@pack_sent
@@pagesize
@@parallel_degree
@@probesuid
@@procid
@@recovery_state
@@rowcount
@@scan_parallel_degree
@@servername
@@shmem_flags
@@spid
@@sqlstatus
@@ssl_ciphersuite
@@stringsize
@@tempdbid
@@textcolid
@@textdbid
@@textobjid
@@textptr
@@textptr_parameters
@@textsize
@@textts
@@thresh_hysteresis
@@timeticks
@@total_errors
@@total_read
@@total_write
@@tranchained
@@trancount
@@transactional_rpc
@@transtate
@@unicharsize
@@version
@@version_as_integer
from http://bbs.chinaunix.net/forum/viewtopic.php?t=533042&show_type=new

到现在为止，还不知道什么是RSS，惭愧：）

SQL — 2005-05-05 10:55:00Z

http://zh.wikipedia.org/wiki/RSS

另外的资料：

名词解释：什么是RSS？

　　讨论与Blog相关的技术，不可不谈的就是RSS，这个缩写在英文中可以有几个源头，并被不同的技术团体做不同的解释。既可以是“Rich Site Summary”，或“RDF Site Summary”，也可以是“Really Simple Syndication”。为什么有这么多含义呢？这还要从RSS的一段今天也没有理清的关系说起。

　　今天肯定有人还记得IE 4刚刚推出来的时候有一个有趣的功能，那就是新闻频道。这个新闻频道的功能与Netscape推出的新闻频道是很相似的(当时Netscape还是市场上领先的浏览器)。为此Netscape 定义了一套描述新闻频道的语言，这就是RSS，只不过Netscape自当时起每况愈下，所以最终也没有发布一个正式的RSS规范(只发布了一个0.9版本)。而微软也在当时推出了支持自己IE的CDF(Channel Definition Format)数据规格，与RSS非常接近。微软试图用新闻频道的功能把“推”(Push)技术变成一个应用主流，并与Netscape抗衡。不过出乎预测的是，“推”技术自始至终没有找到合适的商业模型，而且伴随着其他各类网络特性的出现，也日益无法显现自身的优势。新闻频道在浏览器中的地位最终日暮西山，最后也在IE的后续版本中消失了。

　　新闻频道的确进入了低谷，但是RSS并没有被业界人士所抛弃。过去两年，Blog从一个专业群体开始，逐步成为了网络上最热门的新话题。而RSS成为了描述Blog主题和更新信息的最基本方法。于是RSS这项技术被著名Blogger/Geek戴夫·温那(Dave Winner)的公司UserLand所接手，继续开发新的版本，以适应新的网络应用需要。新的网络应用就是Blog，因为戴夫·温那的努力，RSS升级到了0.91版，然后达到了0.92版，随后在各种Blog工具中得到了应用，并被众多的专业新闻站点所支持。在广泛的应用过程中，众多的专业人士认识到需要组织起来，把RSS发展成为一个通用的规范，并进一步标准化。一个联合小组根据W3C新一代的语义网技术RDF对RSS进行了重新定义，发布了RSS 1.0，并把RSS定义为“RDF Site Summary”。这项工作并没有与戴夫·温那进行有效的沟通，而戴夫则坚持在自己设想的方向上进一步开发RSS的后续版本，也并不承认RSS 1.0的有效性。RSS由此开始分化形成了RSS 0.9x/2.0和RSS 1.0两个阵营，也由此引起了在专业人群中的广泛争论。

　　因为争论的存在，一直到今天，RSS 1.0还没有成为标准化组织的真正标准。而戴夫·温那却在2002年9月独自把RSS升级到了2.0版本，其中的定义完全是全新的模式，并没有任何RSS 1.0的影子。这引发了网络上进一步争议，究竟让一个越来越普及的数据格式成为一个开放的标准，还是被一家公司所定义和控制，成为了争议的焦点。戴夫·温那并没有为自己辩解，他的观点是RSS还需要进一步发展，需要专业人士更明确的定义，不过恐怕这种轻描淡写不能消除人们对RSS“被一家商业公司独占”的担心。

　　前面的铺垫对用户来说也许没有什么太大的意义，可能更多人关心如何在自己的Blog增加RSS输出，这样可以让很多新闻聚合工具(例如CNBlog刚刚推荐的NewzCrawler)很容易找到你并自动获得你在Blog中的更新内容。

　　它是什么：站点用来和其他站点之间共享内容的简易方式(也叫聚合内容)。 RSS使肵ML作为彼此共享内容的标准方式。

　　它代表什么：Really Simple Syndication (或RDF Site Summary，RDF站点摘要)

　　例如：一些免费的软件能够让你阅读那些RSS使能的站点，比如 NewsIsFree 和 Amphetadesk。

　　它有什么用处：让别人容易的发现你已经更新了你的站点，让人们很容易的追踪他们阅读的所有weblogs。

Wikiup

SQL — 2004-11-24 21:37:00Z

黄夜青灯听夜雨，晨钟暮鼓诵经文。

运动

SQL — 2004-11-04 20:49:00Z

在操场上慢跑了才不到三圈，就有点喘，唉，不服老不行啊；想当年，金戈铁马，气吞万里如虎。

该运动了，否则迟早会垮的。

自我原谅

SQL — 2004-10-17 21:16:00Z

好长时间没写东西了，时间总是在自我原谅中消逝......

真正理解了毛主席的一句名言：做一件好事并不难，难得是一辈子做好事。

风流总被雨打风吹去......

驼铃还是蒋大为的好听，李双江的简直没法比，差的不是一点半点。

SQL — 2004-07-25 11:35:00Z

驼铃
送战友，踏征程。
默默无语两眼泪，
耳边响起驼铃声。
路漫漫，雾茫茫。
革命生涯常分手，
一样分别两样情。
战友啊战友，
亲爱的弟兄，
当心夜半北风寒，
一路多保重。
送战友，踏征程。
任重道远多艰辛，
洒下一路驼铃声。
山叠嶂，水纵横。
顶风逆水雄心在，
不负人民养育情。
战友啊战友，
亲爱的弟兄，
待到春风传佳讯，
我们再相逢。

Delphi-世人对你评价到底如何？

SQL — 2004-07-02 21:43:00Z

侯捷在他的译著《C# Primer中文版》的译序中写道：“目前软件业界存在三大主流OOP预言：C++, Java, C#。”，唉，Delphi为何没在其中呢？

崔京浩-父亲

SQL — 2004-06-30 14:53:00Z

找了许久，才找到一个Flash（http://flash.9sky.com/flash_5757.htm），勉强听吧：）。

附：歌词

    那是我小时侯
　　常坐在父亲肩头
　　父亲是儿登天的梯
　　父亲是那拉车的牛
　　忘不了粗茶淡饭  将我养大
　　忘不了一声长叹  半壶老酒
　　
　　等我长大后
　　山里的孩子往外走
　　想儿时一封家书千里写叮嘱
　　盼儿归一袋闷烟
　　满天数星斗
　　
　　都说养儿能防老
　　可儿山高水远他乡留
　　都说养儿为防老
　　可你再苦再累不张口
　　儿只有轻歌一曲和泪唱
　　愿天下父母平安度春秋！

发现一个取我机器IP取错的网站

SQL — 2004-06-18 11:41:00Z

您的真实ＩＰ是：192.168.1.2，操作系统：Windows 2000，浏览器：Microsoft Internet Explorer 6.0

Google搜索，竟然搜到没脾气的老窝

SQL — 2004-06-17 21:31:00Z

Google中搜索“Web App Debugger”，第二页竟然发现没脾气的老窝http://home.hoolee.com/~notemper/my_documents/development/delphi_001.htm，进去欣赏了一阵，嘿嘿。

数据库随笔-查询速度究竟慢在哪里？

SQL — 2004-06-16 16:29:00Z

[问题来源]

Sybase数据库，表RBase_YPCode结构如下：

Create Table RBase_YPCode(
YPBM    char(16)    not null,
YPMC    char(255)   not null,
SJBM    char(16)    not null,
CYBZ    char(1) not null,
YZ char(1) not null,
EQBM    char(8) null,
JDCC    int null,
YPDC    char(1) DEFAULT '2'    null,
DYCWBM char(15)    null,
constraint RBase_YPCode_2260998461 PRIMARY KEY CLUSTERED ( YPBM)
)

表中现有数据1800条，用Select * From RBase_YPCode查询，用了7000~8000ms。何以这么慢？

[测试方法]

方法一：在Delphi中利用TBatchMove从RBase_YPCode中将数据导入RBase_YPCode2（TBatchMove创建，没有主键和其它constraint），然后用Select * From RBase_YPCode查询，用了1400~1500ms。然后加上contraint:

Alter Table RBase_YPCode2
Add Constraint RBase_YPCode_2260998461 PRIMARY KEY CLUSTERED (YPBM)，此时RBase_YPCode2的constraint和RBase_YPCode完全一样，再用Select * From RBase_YPCode2查询，所用时间也在1400~1500ms之间，没有明显变化。

方法二：使用上面创建表的语句（绿色字部分）创建表RBase_YPCode3，然后利用下面SQL往RBase_YPCode3中导入数据：

Insert Into RBase_YPCode3 Select * From RBase_YPCode

然后用Select * From RBase_YPCode3查询，用了5400~6000ms。然后加上contraint，查询时间差不多。

[问题提出]

说明：上面两种方法中加contraint的目的不是为了提高查询速度，仅是为了保持和原表RBase_YPCode3结构一致。

那么，两种方法创建的表的结构一致，数据相同，何以查询时间竟差了将近3000ms？而且，为何新建的表比原来的查询速度也至少快了1000ms？

不解，暂存，留待日后解决吧。

刀郎的歌，也没什么让我羡慕的地方

SQL — 2004-06-14 22:25:00Z

都说刀郎的歌非常好听，于是下载了他的2004年首张个人专辑《2002年的第一场雪》。听了其中几首，也不过如此，不怎么让人羡慕。当然，这纯属于因人而异：我认为不好听，并不等于别人认为不好听——靠，想那么多干嘛？赶紧睡觉去。

BT增加速度有几种方法&使用技巧

SQL — 2004-06-13 15:25:00Z

****增加速度有几种方法：

　　1、公网上网的用户方便了，只要没开防火墙，一般速度会达到下载极限(哪怕只有一个种子);如果有防火墙，要正确设置参数，打开6881~6889端口。

　　2、内网用户速度会很慢，因为在内网下，别人看不到你的机器，只能看到你的网关，如果对方也在内网下，那么你们就不能互传文件。解决方法是用终极武器nat --端口映像(又叫网络地址翻译),其作用是让服务器把指定端口的请求转发到指定的ip上,让其它的机器来响应这些请求,而内网向外网发送的时候不再是像其它网关服务那样随机分配端口,而是用上面指定的端口。可以用的软件有：winroute pro和porttunnel。但如果你的服务器是win2000,并用自带的网络共享功能,那么有更简单的方法在你共享的连接上按右键->属性到公用设定板按下面的设定按钮,系统会弹出设置窗口到服务板,按新增，名称随便填，端口6881，勾选tcp私人网络中的计算机名称或ip填你的本机ip，然后保存,再按同样的方法增加6882-6889端口的映像,把它们通通指向你的计算机不明白的可以看看win2000帮助系统中有关nat的说明。不可忽视的缺点：假如你是校园网的lan，你如何说服网管运行分配端口程序呢？大家各显神通吧！！

　　3、下载时尽量只开一个bt，这样它就会享有最大带宽。如果你打开两个bt，它们就会根据网络情况的不同来分享带宽(我用lan，最大速度400k/s)

　　4、同时尽量不要用其它的下载工具同是下载文件，如ftp等，虽然bt抢线的能力不错，但是还是会受到一定的影响。

　　5、要是下载速度仍不上来，大家就看看自己上网的设备是否是在良好的状态了！比如是否用专用压线工具处理网线接头(rj45接头)等，因为这些都会影响信息的流通！

　　6、终极提速大法：人人为我，我为人人。只有大家自己当种子源，我们才可以享受到更好的资源共享！

****小技巧：

　　我下载中总结出的一些技巧：

　　首先是使用它探知下载前该文件有多少人下载或者连接是否还可用，从而很容易的估算大约下载的速度。

　　当我觉得有必要，并且下载有效的情况下再开启bt客户端下载我需要的文件。

　　1.尽可能在看到bt链接时，不要直接点击，而是右键->目标另存为，将其保存为一个本地文件，待保存完毕点打开即可。这样做的好处，前面已经说了，可以方便续传，不用续传时满世界找原来的链接。

　　2.一开始速度慢，不要太心急！很多人往往说好慢啊，只有几k的速度，要数百分钟，于是cancel了。其实bt下载的特点就是这样的，先开始很慢，只有几k，然后逐渐增长到上百k。这个过程从你看见1k的速度开始，一般要2-5分钟。所以只要你载的东西不是太过时，以致种子都失效了，就耐心等个几分钟吧。

　　3.尽量选择下载200-700m的文件，特别是rmvb格式的电影。笔者总结出来，dvd-rmvb格式的电影用bt下载最方便，速度也最快；其它格式如dvdrip文件太多，下载之前start过程比较慢，而且会自做主张的建一堆目录和文件;而对于较小的文件，比如40m以下的文件，根本体现不出bt的优点，按照刚才第二点说的，速度还没到峰值就结束了

　　4.由于bt下载的就是很大的文件，就笔者来说，有空的时侯几天就下了30多g，这样的反效果是文件的大量增删导致系统变慢，这时可以用诺顿等工具软件来整理一下机子！！

SQL