Hello，Chicago! 芝城父老，别来无恙， If there is anyone out there who still doubts that America is a place where all things are possible, who still wonders if the dream of our founders is alive in our time, who still questions the power of our democracy, tonight is your answer. 余尝闻世人有疑，不知当今美利坚凡事皆可成就耶？开国先贤之志方岿然于世耶？民主之伟力不减于昔年耶？凡存诸疑者，今夕当可释然。 It’s the answer told by lines that [...]

昨天在兵马俑上有人用英文发文述说相思之苦。。 闲的无聊 帮他翻译了一下  呵呵   原文： Come to Xi’an and choose XJTU far from Jiangsu 2 years ago, which was all aim to forget a person. Never call her this 2 years. Never meet her any time. Never mention her in any situations. Force myself not to think of her, not to recall the old [...]

  感谢吴春同学送的小狗   过完春节再找一只睁眼睛的牛儿。。

相信你在使用Google或者Baidu搜索的时候，肯定碰到过他们的关键词提示。 对于搜索引擎来说，他们有一整套分词技术及完整的词库。而对于一般简单的PHP应用来说，做到这种完善的分词又是很困难的。 其实php中有两个函数，可以近似的完成这样的功能。 这两个函数就是：levenshtein 和 similar_text 以下分别是这两个函数的官方解释： http://www.php.net/manual/en/function.levenshtein.php http://www.php.net/manual/en/function.similar-text.php 我们来简单看一下使用这两个函数的效果。 echo levenshtein(“ubuntu”,”ubuntw”);     echo “<br>”;     echo levenshtein(“ubuntu”,”aubvntu”);         echo “<br>”;     echo levenshtein(“ubuntu”,”vbvntw”);         echo “<br>”;     echo levenshtein(“ubuntu”,”ubuntu”); 这段代码的输出是： 1 2 3 0 也就是说，对于levenshtein函数，两个字符相似度越高，其返回值越小，如果相等，则函数返回0。 再来看看similar_text函数 similar_text(“ubuntu”,”ubuntw”,$a);              echo $a;     echo “<br>”;      similar_text(“ubuntu”,”aubvntu”,$a);          echo $a;         echo “<br>”;      similar_text(“ubuntu”,”vbvntw”,$a);          [...]

 　　一、什么是索引？ 　　索引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表的所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比顺序扫描记录快100倍。 　　 　　假设我们创建了一个名为people的表： 　　 　　CREATE TABLE people ( peopleid SMALLINT NOT NULL, name CHAR(50) NOT NULL ); 　　 　　然后，我们完全随机把1000个不同name值插入到people表。下图显示了people表所在数据文件的一小部分： 　　 　　可以看到，在数据文件中name列没有任何明确的次序。如果我们创建了name列的索引，MySQL将在索引中排序name列： 　　 　　对于索引中的每一项，MySQL在内部为它保存一个数据文件中实际记录所在位置的“指针”。因此，如果我们要查找name等于“Mike”记录的peopleid（SQL命令为“SELECT peopleid FROM people WHERE name=’Mike’;”），MySQL能够在name的索引中查找“Mike”值，然后直接转到数据文件中相应的行，准确地返回该行的peopleid（999）。在这个过程中，MySQL只需处理一个行就可以返回结果。如果没有“name”列的索引，MySQL要扫描数据文件中的所有记录，即1000个记录！显然，需要MySQL处理的记录数量越少，则它完成任务的速度就越快。 　　 　　二、索引的类型 　　MySQL提供多种索引类型供选择： 　　 　　普通索引 　　这是最基本的索引类型，而且它没有唯一性之类的限制。普通索引可以通过以下几种方式创建： 　　创建索引，例如CREATE INDEX <索引的名字> ON tablename (列的列表); 　　修改表，例如ALTER TABLE tablename ADD INDEX [索引的名字] (列的列表); 　　创建表的时候指定索引，例如CREATE TABLE tablename ( [...], INDEX [索引的名字] [...]

要选择有助于使查询执行更快的列，应遵循如下规则（这里，“BLOB 类型”应该理解为即包含B L O B也包含TEXT 类型）：    ■ 使用定长列，不使用可变长列。这条准则对被经常修改，从而容易产生碎片的表来说特别重要。例如，应该选择CHAR 列而不选择VARCHAR 列。所要权衡的是使用定长列时，表所占用的空间更多，但如果能够承担这种空间的耗费，使用定长行将比使用可变长的行处理快得多。    ■ 在较短的列能够满足要求时不要使用较长的列。如果正使用的是定长的CHAR 列，应该使它们尽量短。如果列中所存储的最长值为40 个字符，那么就不要将其定义为CHAR ( 2 5 5 )；只要定义为CHAR(40) 即可。如果能够使用MEDIUMINT 而不是BIGINT，表将会更小（磁盘I/O 也较少），其值在计算中也可以处理得更快。    ■ 将列定义为NOT NULL。这样处理更快，所需空间更少。而且有时还能简化查询，因为不需要检查是否存在特例NULL。    ■ 考虑使用ENUM 列。如果有一个只含有限数目的特定值的列，那么应该考虑将其转换为ENUM 列。ENUM 列的值可以更快地处理，因为它们在内部是以数值表示的。    ■ 使用PROCEDURE ANALYSE( )。如果使用的是MySQL3.23 或更新的版本，应该执行PROCEDURE ANALYSE( )，查看它所提供的关于表中列的信息：     相应输出中有一列是关于表中每列的最佳列类型的建议。第二个例子要求PROCEDURE ANALYSE( ) 不要建议含有多于16 个值或取多于256 字节的ENUM 类型（可根据需要更改这些值）。如果没有这样的限制，输出可能会很长；ENUM 的定义也会很难阅读。根据PROCEDURE ANALYSE( ) 的输出，会发现可以对表进行更改以利用更有效的类型。如果希望更改值类型，使用ALTER TABLE [...]

   在谈论2038问题时，我们要知道，并不是wonderware软件会有2038问题，基本上所有的软件（跟时间有关），从大规模的ERP、MES到自动化组态软件、办公软件、聊天软件，从大型工作站到我们用的手机通讯都可能会出现2038问题，所以我们不要太惊慌，但也不能回避。 　　资料中显示Y2038 bug将于2038年1月19日(星期二)03：14：07am(GMT)正式爆发，届时人们对千年虫问题的预言可能将一一实现，比如手机网络工作不正常，卫星脱离轨道，型号较老的电脑软件软硬件无法正常工作等。 　　什么是Y2038 bug 　　Time_t是C/C++等编程语言在内部代表/存储日期和时间的一种数据类型。Time_t实际上是一个代表秒数的整数，当它的值为0时，代表的时间是1970年1月1日0：00：00；当Time_t=60时，则表示1970年1月1日0：01：00，依此类推。 　　所有32位电脑系统都用带符号32位整型来存储time_t的值，也就是说t_time只能用31位二进制数来表示(第一位用来表示正负号)，而其最大值转换为十进制是2147483647，换算成日期和时间刚好是2038年1月19日03：14：07am(GMT)，而这一秒过后，t_time的值将变成-2147483647，代表的是1901年12月13日8：45：52pm，这样32位软硬件系统的日期时间显示就都乱套了。另外，无法接受time_t为负值的其他功能也将返回错误。 　　举个实际的例子来说，登陆上Yahoo messenger，给好友发个消息，恩没问题，现在把系统时间更改为2038年1月19日03：14：07am，此时如果再发消息Yahoo messenger就将崩溃。 　　为何担忧？ 　　也许有人觉得2038年还早着，无需担心这个问题。不幸的是，上世纪60年代的程序开发人员也抱有类似的错误想法，并由此导致了Y2K问题，给全球IT页带来数十亿美元的损失。 　　要知道时间对于许多电脑程序来说都非常重要，操作系统、数据库程序、电子表格软件、实时控制系统等无不涉及到时间。因此我们必须在Y2038 bug爆发前做好充足的准备。 　　尽管到2038年，桌面PC和服务器基本上都将升级到64位甚至128位，但仍会有许多使用中的32位甚至更古老的系统。即使是在32位系统盛行的今天，大多数嵌入式系统仍是8位或16位的，而小型嵌入式系统的数量其实比台式机更多。 　　如何应对？ 　　Y2038问题和Y2K一样难缠，其中一种解决办法就是用位数更多的数据类型来存储日期和时间。如果使用64位数据类型，time_t最大可以表示公元292000000000年，是宇宙估计年龄的20倍，最起码看到这篇文章的各位都不会再遇到什么YXXXX问题了。 　　目前对于Y2038 bug的影响有多大还存在争论，但有一点可以肯定的是：有备无患。相信我们能像克服Y2K问题那样圆满解决Y2038问题。       有人把2038问题称作“千年虫二世”，这个比喻非常恰当。        用32位元来记录时间，正值表示为1970以後，负值则表示1970年以前。我们可以很简单地计算出其时间领域：   2^31/86400(s) = 24855.13481(天) ~ 68.0958(年)   1970+68.0958 = 2038.0958   1970-68.0958 = 1901.9042   时间领域为[1901.9042,2038.0958]。   准确的时间为2038年一月十八日星期一晚上十点十四分七秒。那一刻，时间将会转为负数，变成1901年十二月十三日黑色星期五下午三点四十五分五十二秒。