PostgreSQL 与 MySQL 相比，优势何在？

Pg 没 MySQL 的各式各样坑

MySQL 的各式各样 text 表头有相同的管制, 要全自动界定 small text, middle text, large text… Pg 没那个管制, text 能全力支持各式各样大小不一.

依照 SQL 国际标准, 做 null 推论无法用 = null, 根本无法用 is null

the result of any arithmetic comparison with NULL is also NULL

但 pg 能增设 transform_null_equals 把 = null 译成 is null 防止踩坑

许多人如果碰到过 MySQL 里须要 utf8mb4就可以表明 emoji 的坑, Pg 就没那个坑.

MySQL 的外交事务隔绝等级repeatable read 并无法制止常用的mammalian预览, 得上锁就可以, 但乐观锁会负面影响操控性, 全自动同时实现乐观锁又繁杂. 而 Pg 的列里有暗藏的乐观锁 version 表头, 预设的 repeatable read 等级就能确保mammalian预览的精确性, 因此又有乐观锁的操控性. 内含两个各资料库对隔绝等级的犯罪行为差别较为进行调查:

http://www.cs.umb.edu/~poneil/iso.pdf

MySQL 不全力支持数个X84EB96HR同一字符串中取 id, 而 Pg 能.

MySQL 不全力支持 OVER 从句, 而 Pg 全力支持. OVER 从句能单纯的化解 “两组取 top 5” 的此类难题.

基本上任何人资料库的子查阅 (subquery) 操控性都比 MySQL 好.

更多的坑:

http://blog.ionelmc.ro/2014/12/28/terrible-choices-mysql/

许多人踩完坑了, 以为换个资料库还得踩一次, 所以很抗拒, 事实上不是!!!

Pg 不仅仅是 SQL 资料库

它能存储 array和 json, 能在 array 和 json 上建索引, 甚至还能用表达式索引. 为了同时实现文档资料库的功能, 设计了 jsonb的存储结构. 有人会说为什么不用 Mongodb 的 BSON 呢? Pg 的开发团队曾经考虑过, 但是他们看到 BSON 把 [“a”, “b”, “c”] 存成 {0: “a”, 1: “b”, 2: “c”} 的时候就决定要重新做两个 jsonb 了… 现在 jsonb 的操控性已经优于 BSON.

现在往前端偏移的开发环境里, 用 Pg + PostgREST 直接生成后端 API 是非常快速高效的办法:

begriffs/postgrest · GitHub

postgREST 的操控性非常强悍, 两个原因就是 Pg 能直接组织返回 json 的结果.

它全力支持服务器端脚本: TCL, Python, R, Perl, Ruby, MRuby … 自带 map-reduce 了.

它有地理信息处理扩展 (GIS 扩展不仅限于真实世界, 游戏里的地形什么的也能), 能用 Pg 搭寻路服务器和地图服务器:

PostGIS — Spatial and Geographic Objects for PostgreSQL

它自带全文搜索功能 (不用费劲再装两个 elasticsearch 咯):

Full text search in milliseconds with PostgreSQL

不过一些语言相关的全力支持还不太完善, 有个 bamboo 插件用调教过的mecab 做中文分词, 如果要求较为高, 还是自己分了词再存到 tsvector 较为好.

它全力支持 trigram 索引.

trigram 索引能帮助改进全文搜索的结果:

PostgreSQL: Documentation: 9.3: pg_trgm