刚看到这个题目的时候，是不是觉得很奇怪？为什么这样的标题，它的TAG却是项目管理？事情要从博客园的某个博客说起，开始的时候我也以为是小孩治病方面的问题，后来才看出，确实是项目管理方面的。

仔细想想，确实和项目管理还有程序开发有关。说和做，提出方案和解决方案确实需要有一个全局把控的人。不能因为说A数据库不好，我们就换成B数据库，结果换到B数据库后还是不行；其实不是B数据库不行，而是不会配置B数据库而己。

原文地址：http://www.cnblogs.com/caidehui/archive/2008/12/18/1357692.html

内容如下：

     孩子病了，腹泻。去了儿童医院，开了药，吃了几天，没用。去了医大二院，也没用。昨天再去医大二院，换一大夫。大夫仔细的询问了病的情况，药的情况。

      开一方，无药，只有吃法。空腹、25ml水，服后半小时吃东西。其效入神，立时止泻。

      同样的药，效果确实截然不同的。这世上，庸医，良医原来只是这点不同。

    企业所面临的问题，也是如此。

      Review是经过业界多年，上千项目验证了的好东西。我们引进来也有年月了，可很多项目做的实在不到位，为什么呢？

      非项目之过也，实乃开方的人没有考虑如何有效的发挥作用也。  

      基于EV的进度管理，这个最佳实践，是进度管理中最重要的实践之一。我们引进后，还没有起到我想像中的作用。什么原因？非工具之过、使用者之过，乃我之过也。

      还有很多类似的情况，东西是好的，到了我们的手上就发挥不了作用，那是因为我们并没有真正的掌握其用法。

   对于那些怀疑药的作用的人来说，则是另外一个范畴的了。

      好多年前，中国的思想领域也是经历了一番挣扎的。现代的社会制度，多来之于国外的研究与实践。现代的经济体系，也多来之于国外。于是有守旧者埋怨有些人认为：外国的月亮比中国的圆；也有人高呼，其实外国的月亮不圆。

     这二者，我想其中应该有很大一部分不是谁比谁圆的问题，而是拿来以后如何应用的问题。既有遵循原来的精髓，又要在中国的环境中发挥作用的问题。

     OO、RUP来到中国的时候，不也是讥讽有之，尊崇有之吗？

      现在的中国社会看起来更成熟了一点，更开放了一点，更能容纳各种不同的思想了一点（这里不是指意识形态的问题）。所以类似的争论就少了，如何有效的应用的讨论就多了。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

膘叔的话：你看完了，怎么想呢？你又会怎么做呢？从自身找原因？从别人身上找？唉。。不是你的项目，你管不了？总之，解决方案你自己心里有数吗？

平时我们取得location的search的时候，往往都是要用location.search，然后根据取回的结果集再处理

1、先判断第一位是否是“?”，如果是则从?开始往后面处理

2、写程序以&开始分隔，当然得先用unescape，或者用那个urldecode（具体的名字不记得了）处理一下，把&之类的处理一下

3、以=分隔，这样才能可以取得一一对应的值。

现在方便了。jQuery有这样的插件了。。。。

原文来自：http://www.cssrain.cn/article.asp?id=1204

内容如下：

例如 当前你的URL是：
http://www.cssrain.cn/index.php?test=1&kk=2

如果想获取test，则可以引入插件后，
用如下方法获取：
var test = $.query.get('test');

如果参数有多个相同的名称 ，则可以这样：
var arr = $.query.get('testy');
输出：  [ 值1 ,  值2,  值3...]

如果要获取多个相同名称中的某一个，可以这样：
var arrayElement = $.query.get('testy[1]');

此插件不仅能获取参数，也能设置参数。

设置一个参数：
var newUrl = $.query.set("section", 5).toString();
输出  ： "?section=5"

设置两个参数：
var newUrl = $.query.set("section", 5).set("action", "do").toString();
输出 :  "?action=do&section=5"


删除一个参数：
var oldQueryAgain = $.query.REMOVE("type");

清空所有参数：
var emptyQuery = $.query.empty();

复制所有参数：
var stillTheSame = $.query.copy();


插件地址：
http://plugins.jquery.com/project/query-object

有时候我们不得不通过更改form的action来进行提交数据。当然大多数情况下，我们都是通过隐藏的字段来使action得到不同的数据。比如我们form的action是search.php，那么我们都是通过隐藏字段来使我们通过search.php搜索不同值，比如<input type="hidden" name="action" value="article">然后在search.php里面通过$_POST['action']=='article'来知道我们搜索的内容是文章而不是其他。

但如果我们搜索页面并非只有一个入口search.php怎么办？比如我们的全文搜索是search.php，搜索文章是search_article.php，搜索新闻是search_news.php。怎么办？当然我们可以通过下拉框的值来更改FORM的action，就可以了。

简单代码如下，

电脑重装，什么东西最让你郁闷？密码。。。是的，密码
网络密码，论坛密码，乱七八槽的，你都记得住吗？还在用大脑？还是用记事本，用软件？
所说，人可以记忆的复杂密码一般为7个左右。所以，密码不要设的太多。
但是自己的设的密码还能猜呢，别人设的怎么办？比如我们的无线网络，在N多地方登录过，你怎么记得清每一处的密码？
推荐这款软件，可以让你把系统使用过的无线密码统统翻译出来。试过有效。

软件下载地址：http://www.hanzify.org/index.php?Go=Show::List&ID=12260
汉化作者：南方的雨
软件介绍：WirelessKeyView 让你可以恢复 Windows 操作系统（非第三方产品）存储的无线网络密匙（WEP/WPA）。该软件采用十六进制和 Ascii （如果提供）码显示带有适配器名称和用户图形界面的密匙。该信息可以被拷贝到剪贴板或者导出为 Text/HTML/XML 文件格式。该软件不需要进行安装

试用情况：主要是两个文件，一个EXE，一个INI文件，运行后会生成一个CFG文件，没有广告，仅在帮助的左下角有一个南方的雨的名称和链接。其余干干净净。当然，如果你不喜欢中文版，你就把那个ini文件删除就行了

为了保持作者原有的格式，和他的URL版本的邮箱，我就不做更改了。其实世界上很多事情都是那么巧的，php focus群里的朋友还在问我数据库是否能够直接拷了就能使用。我的解释是4.0以下的版本都可以拷的，从4.1开始尽量使用mysqldump，但是sundj说，对于MYISAM类型的数据库和表，是可以直接COPY的。对于INNODB则不行。然后打开日常订阅的一些RSS，就发现了这篇文章 。。。套用范伟老师的话：缘份呐

原文如下：

作/译者：叶金荣（Email: ），来源：http://imysql.cn，转载请注明作/译者和出处，并且不能用于商业用途，违者必究。

前言

InnoDB存储引擎满足了MVCC和ACID特性，在需要支持事务的环境下必不可少。有些环境下，采用InnoDB可能效果比MyISAM还要来 的好。不过，在很多人眼中看来，InnoDB表空间文件由于无法实现跨服务器平滑迁移，因此不愿意使用。实际情况真是这样吗？本文就来探讨一下 InnoDB表空间文件的平滑迁移可能性。

如何迁移？

从MySQL文档中我们了解到，InnoDB的表空间可以是共享的或独立的。如果是共享表空间，则所有的表空间都放在一个文件 里：ibdata1,ibdata2..ibdataN，这种情况下，目前应该还没办法实现表空间的迁移，除非完全迁移，因此不在本次讨论之列；我们只讨 论独立表空间的情况。

不管是共享还是独立表空间，InnoDB每个数据表的元数据(metadata)总是保存在 ibdata1 这个共享表空间里，因此该文件必不可少，它还可以用来保存各种数据字典等信息。数据字典中，会保存每个数据表的ID号，每次发生数据表空间新增时，都会使 得该ID自增一个值(++1)，例如：CREATE TABLE xx ENGINE = InnoDB / ALTER TABLE xx ENGINE = InnoDB 都会使得ID值增加。
有了上面的理解，想要实现InnoDB表空间文件的平滑迁移就很容易了，呵呵。下面是一些例子：
假定我们有2台DB主机，一个是A，一个B；现在想把A上的某个InnoDB表空间文件迁移到B上直接用。

一、迁移失败的例子

直接从A上把表空间文件 yejr.ibd 拷贝到 B 上后，导入表空间，报错，无法使用。这是由于A，B上创建该表时的顺序不一致，导致表的ID不一样，无法导入。
注意：，在这里，表空间文件直接拷贝的前提是该表空间处于"干净"状态下，也就是所有的数据均已经刷新到磁盘中，否则可能导致无法使用或部分数据丢失。
1. 在B上将旧的表空间废弃

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr DISCARD TABLESPACE;
Query OK, 0 rows affected (0.00 sec)

2. 拷贝到目标机器

scp yejr.ibd B:/home/mysql/yejr/yejr.ibd
....

3. 启用该表空间

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr IMPORT TABLESPACE;
ERROR 1030 (HY000): Got error -1 from storage engine

4. 查看错误

InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: Error: trying to open a table, but could not
InnoDB: open the tablespace file './test/b.ibd'!
InnoDB: Error: cannot reset lsn's in table `test/b`
InnoDB: in ALTER TABLE ... IMPORT TABLESPACE

5. 很明显，是权限的问题，修正过来，然后重新导入

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr DISCARD TABLESPACE;
ERROR 1030 (HY000): Got error -1 from storage engine

6. 怎么还是错误？继续看日志

InnoDB: Error: tablespace id in file './yejr/yejr.ibd' is 15, but in the InnoDB
InnoDB: data dictionary it is 13.
InnoDB: Have you moved InnoDB .ibd files around without using the
InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE?
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting.html
InnoDB: for how to resolve the issue.
InnoDB: cannot find or open in the database directory the .ibd file of
InnoDB: table `yejr/yejr`
InnoDB: in ALTER TABLE ... IMPORT TABLESPACE

从上面的日志得知，由于在A服务器上，yejr表的ID是15，而在B服务器上，yejr表的ID却是13，二者不一致，因此迁移失败。
既然只是因为ID不一样，而且有了上面的理论基础，我们完全可以人为的让它们的ID一致嘛，请看下面的第2次尝试。

二、人工干预下的成功迁移

1. 上面的例子中，B上面的yejr表ID为13，而A上面为15；因此只需要让B上的yejr表ID增加2就可以了。

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr RENAME TO yejr1;
Query OK, 0 rows affected (0.00 sec)
#这个时候,yejr的ID变为14
(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr1 RENAME TO yejr;
Query OK, 0 rows affected (0.00 sec)
#这个时候,yejr的ID变为15

2. 然后，我们再导入

(root@imysql.cn/17:52:47)[yejr]>ALTER TABLE yejr IMPORT TABLESPACE;
Query OK, 0 rows affected (0.00 sec)
(root@imysql.cn/17:52:47)[yejr]>select count(*) from yejr;
+----------+
| count(*) |
+----------+
|        3 |
+----------+
1 row in set (0.00 sec)

看到了吧，成功了，呵呵。想要让他ID增加的方式也可以重复创建表，根据实际情况或者个人喜好而定了。
以上测试均在mysql 5.0.67版本下通过，只不过显示数据稍作处理了。

原文URL：http://imysql.cn/2008_12_17_migrate_innodb_tablespace_smoothly