关于链接字符串，可以参考 http://docs.php.net/manual/zh/function.pg-connect.php， 注意，旧的多参数语法 $conn = pg_connect(“host”, “port”, “options”, “tty”, “dbname”) 已经不提倡使用，但是依然可以使用。

2. PostgreSQL 里面不需要进行类似于MySQL中的mysql_select_db操作。

3. MYSQL_ASSOC?
mysql_fetch_array() 中可选的第二个参数 result_type 是一个常量，可以接受以下值：MYSQL_ASSOC，MYSQL_NUM 和 MYSQL_BOTH。本特性是 PHP 3.0.7 起新加的。本参数的默认值是 MYSQL_BOTH。 如果用了 MYSQL_BOTH，将得到一个同时包含关联和数字索引的数组。用 MYSQL_ASSOC 只得到关联索引（如同 mysql_fetch_assoc() 那样），用 MYSQL_NUM 只得到数字索引（如同 mysql_fetch_row() 那样）。
而针对postgreSQL也有pg_fetch_array()函数，返回一个与所提取的行（元组/记录）相一致的数组。如果没有更多行可供提取，则返回 FALSE。 result_type 是可选参数，控制着怎样初始化返回值。result_type 是一个常量，可以有以下取值：PGSQL_ASSOC，PGSQL_NUM 和 PGSQL_BOTH。取值为 PGSQL_ASSOC 时 pg_fetch_array() 返回用字段名作为键值索引的关联数组，取值为 PGSQL_NUM 时用字段编号作为键值，取值为 PGSQL_BOTH 时则同时用两者作为键值。默认值是 PGSQL_BOTH.

4. php操作mysql数据库,可以使用mysql_unbuffered_query. 但是操作postgresql无相关的函数,如何替换？

mysql_unbuffered_query这个函数可到这里看说明。 http://php.liukang.com/manual/zh/function.mysql-unbuffered-query.php
php对postgresql操作好像没有这样的函数，但可以用postgresql的游标达到目标。参考 http://www.pgsqldb.org/pgsqldoc-8.1c/sql-declare.html

如果没有声明 WITH HOLD，那么这个命令创建的游标只能在当前事务中使用。使用 BEGIN， COMMIT 和 ROLLBACK 定义一个事务块。

如果声明了 WITH HOLD，并且创建该游标的事务成功提交， 那么游标还可以在同一会话随后的事务里访问。（但如果创建它的事务回滚，那么游标被删除。） 带着 WITH HOLD 创建的游标是用一个明确的 CLOSE 命令，或者是会话终止来关闭的。 在目前的实现里，由一个游标代表的行是被拷贝到一个临时文件或者内存区里的，这样他们就仍然可以在随后的事务中被访问。

在定义一个要用来向后抓取的游标的时候，我们应该声明 SCROLL 选项。 这个是 SQL 标准要求的。不过，为了和早期的版本兼容， PostgreSQL 在没有 SCROLL 的时候也允许向后抓取， 只要游标的查询计划简单得不需要额外的开销就可以支持它。 不过，我们建议应用开发人员不要依赖于使用没有带着 SCROLL 定义的游标的后向查找功能。如果声明了 NO SCROLL，那么不管怎样都会禁止向后抓取的功能。

在 SQL 标准中游标只能在嵌入 SQL （ESQL） 的应用中使用。 PostgreSQL 服务器没有一个明确的 OPEN 语句；一个游标被认为在定义时就已经打开了。 不过，PostgreSQL嵌入的 SQL 预编译器， ecpg， 支持 SQL92 习惯，包括那些和DECLARE和OPEN相关的语句。

5. Full text index

MySQL comes with full-text search, but can only be run on the MyISAM storage engine. [12]

A 3rd party add-on to MySQL, Sphinx Fulltext Search Engine allows it to support full-text searches of InnoDB tables.

PostgreSQL 8.2 has full text search in the tsearch2 module.

PostgreSQL 8.3 integrates tsearch2 into the core: “TSearch2, our cutting-edge full text search tool, has been fully integrated into the core code, and also has a cleaner API.” [13]

参考http://blog.chinaunix.net/u/11565/showart_1848766.html 进行tsearch2支持的全文搜索.

6. && –> AND

俺发现，如果睡得晚，就会做些奇怪的梦来。今晨4：00才入睡，居然梦到了李一男同学（现任百度首席技术官 CTO），他说自己花了好长时间终于搞懂了百度是怎么一回事，然后鼓励我们大家也去搞搞。我建议老李多看看全文检索，以及文言文的分词，当然也说要和地图结合起来，毕竟百度有这么好的百度国学部分，以及一男同学他前几天主持更新的百度地图。不好好利用，简直太可惜了。

谈到中文分词，它牵涉到汉语分词、未定义词识别、词性标注以及语言特例等多个因素。目前大概主要有三个方法：辞典分词法、统计分词法以及规则分词法（也就是基于语义的分词法）。

（1）辞典分词法：一般是最大匹配算法，有正向匹配和逆向匹配之分，当然有其他算法，就像蒋志欣所提及的双序匹配法。

（2）统计分词法：前提就是单词是有字节构成的，通过研究组词的概率来判断是否是在此分词，李海波举了一个很形象例子说，比如“我”，单独出现的概率是“50%”，“我爱”组合出现的概率是“10%”，那么“我爱”就不是一个词。比如“北京”，“北京”在很多文章中老放在一起，那么就应该在一起，是一个地名。一

（3）规则分词法：该分词法最有名的实例就是中科院开发的ICTCLAS汉语分词系统。该系统根据他们自己介绍说，采用了层叠隐马尔可夫模型（Hierarchical Hidden Markov Model），将汉语词法分析的所有环节都统一到了一个完整的理论框架中。”

提到辞典分词法，不得不提到到一个人，来自中国台北的蔡志浩同学。他写了一篇名为”MMSEG: A Word Identification System for Mandarin Chinese Text Based on Two Variants of the Maximum Matching Algorithm“ 的文章，介绍了MMSeg，一个现在很通用的中文分词方法,当今很多分词机都受到了蔡同学的启迪，诸如我一会要向大家介绍的 pymmseg-cpp。coreseek.cn的李沫南同学翻译了这篇文章，这里给大家一个basic idea,

蔡同学提出，中文行文有其自己的规则，所以我们可以通过总结这些行文规则来进行分词。在MMSEG里面，有两个需要注意的概念，一个为Chunk，它包含依据上下文分出的一组词和相关的属性，包括长度(Length)、平均长度(Average Length)、标准差的平方(Variance)和自由语素度(Degree Of Morphemic Freedom)；另一个为规则（Rule），实际上就是过滤器(Filter)，过滤掉不符合要求的chunk。MMSeg分词算法中涉及了4个规则：

• 规则1：取最大匹配的chunk (Rule 1: Maximum matching)
• 规则2：取平均词长最大的chunk (Rule 2: Largest average word length)
• 规则3：取词长标准差最小的chunk (Rule 3: Smallest variance of word lengths)
• 规则4：取单字词自由语素度之和最大的chunk (Rule 4: Largest sum of degree of morphemic freedom of one-character words)

这4个规则符合汉语成词的基本习惯，所以蔡同学希望通过这四个规则来近似的进行中文分词。大概就是这样样子，通过以上的规则参数，然后进行匹配，匹配主要有两种方式简单最大匹配(Simple maximum matching)和复杂最大匹配(Complex maximum matching)。这里就不再熬述，大家直接看他的原文吧，比较清晰的。

关于中文分词，几个比较有名的是庖丁，bamboo，mmseg（以及由mmseg派生的coreseek，pymmseg-cpp、rmmseg等）、IK Analyzer。关于理论方面，大家不妨看看这个博客（http://blog.csdn.net/jyz3051/category/356808.aspx?PageNumber=1）。

关于我最近的使用，我比较倾向于使用coreseek以及pymmseg-cpp.使用coreseek因为他和sphinx结合的比较紧，首先做全文检索，紧接着就可以做分词，而用pymmseg-cpp，由于是基于python，而像bamboo和庖丁都是基于java的，我这人本身就有点java fool，所以还是喜欢python一些。同时cpp是通过ctypes和python链接，方便我自己定义一些自己的匹配方式，对于今后我要做文言文的中文分词，单单从分词方面来讲，可能是比较小巧精干的东西。关于pymmseg-cpp的研发历程，可以看看free mind同学的帖子。大概就是这么多，本想和大家讨论使用心得，等到下一个帖子吧。

参考文献：

• http://blog.csdn.net/marising/archive/2009/04/16/4083650.aspx
• http://www.javaeye.com/wiki/interview/1899-ik-analyzer
• http://nzinfo.spaces.live.com/Blog/cns!67694E0B61E3E8D2!344.entry?wa=wsignin1.0&sa=523994764
• http://lifegoo.pluskid.org/?p=431

我进一步询问了Szonyi如何得到如上结论，他提及了群体传记学（Prosopography）作为理论基础，CBDB对群体传记学有着如下的定义，“通过对一群历史行为人的生平做集体性的研究，探讨这群历史人物共有的背景特征。其采用的方法要先建立一个研究范围，然后就此提出一组相同的 问题──这些问题可以是关于出生与死亡、婚姻与家庭、社会出身与所继承的经济地位、居住地、教育、个人财富之数量与来源、职业、宗教、宦历等方面的。然 后，将此研究范围中所有人物的各类信息加以罗列、组合，再通过对这些信息的考察找出具有显著意义的变量。研究者可以检测这些信息的内在相关性，及其与其他 行为形式或行动形式的相关性。” 。Szonyi说他在进行这项研究的过程中，首先收集了大量关于唐宋结为婚姻的两家人的父亲的生平旅行资料，然后在地图中标注出他们这一生中所到过的地方，以时间先后顺序连线，通过大量的样本，发现多数这些结为婚姻的亲家爸们，更多的是在某个地方相识，然后彼此才为儿女订立终身大事（在唐宋没有飞机，火车、互联网、手机、所以网恋和快速的异地交往会比较少，所以一般来说，只有两者在同一个地方的时候，才有进行交流的可能，我想这也是Szonyi老师的一项假设前提之一，当然了，这也有点common sense了）。然后Szonyi发现，对于唐朝来说，这些连线一般来说跨度比较大，交点在长安城居多。而对于宋朝，这些连线一般较短，而且交点分布混杂，在某一个区域居多。

虽然这仅仅是一个简单的例子，但是可见群体传记学，或者说基于GIS的群体传记学对于历史研究越来越重要，群体传记学最初是1970年提出，曾经一度被学者们热烈讨论，但而后又沉寂了，到了本世纪初，基于计算机技术，特别是GIS和数据库技术的发展，历史学家又重新回到了对群体传记学的研究。CBDB项目也随之启动，而今天我觉得我再提群体传记学这个概念，更多的，其实是因为社会网络分析（SNA）这几年飞速的发展。我觉得从基于GIS+DB的群体传记学向基于SNA+GIS+DB的群体传记学的进化，是一个必然趋势。虽然之前有人也用SNA，但是还是最初步的，甚至只是可视化层面的，如果能对于SNA的一些概念比如临近度、中心度、集聚度进行分析，大概可以得到一些新的知识。

同时，我觉得还有一个问题值得大家关注，就是所谓的full-text search技术。现在比较流行两种模式是数据库直接的fts或者是基于插件的fts。两者的开源代表为postgresql+TSearch2以及Sphinx。当然了，对于中文检索，甚至文言文检索，还需要中文分词。我会在今后的文章里面和大家详述有关full-texts search的相关技术。这样可以通过分析原始的文档得到两个对象之间的关系，而不需要手工的搜寻。