我主要考察的数据库有MySQL、PostgreSQL和MongoDB。对于这三种数据库，我都有一些经验，其中以MySQL的经验最为“丰富”，毕竟之前做的小项目都是用MySQL。 我对数据库的要求如下。 （1）支持地理位置查询。比如，两地间的距离，一个景点方圆几公里都有什么景点，离一个景点最近的景点是什么…… （2）适合快速开发，有成熟的ORM/ODM。 （3）容易部署，至少主从（master/slave）的部署不复杂。 （4）开发效率高。 其中第一条是决定性的，因为地理位置查询是我们很多操作的基础。MySQL因此出局（其实MySQL还是可以做类似的事情的，只是当时不懂），剩下PostgreSQL和MongoDB。PostgreSQL是GeoDjango的默认数据库，而GeoDjango提供了一套强大的可开发GIS的系统。此外，在地图上进行遮罩这种很高阶的功能GeoDjango也支持。因此，GeoDjango和PostgreSQL便成为我的首选。我从一个开源的项目——everyblock[\[11\]](#anchor211)开始学习GeoDjango和PostgreSQL。 然而，两个月后，我发现GeoDjango/PostgreSQL的学习成本和曲线太高，要掌握它及其背后复杂的library非一日之功。*复杂是创新的敌人，当你把全部精力用在应对复杂后，你已经无力去思考去创新。*因此，我决定舍弃GeoDjango/Postgres和在此基础上完成的项目，转向MongoDB。 MongoDB仅仅支持范围查询（within）和附近查询（near），对于我们的项目来说，最核心的功能已经能够实现，目前基本够用了。相对于Postgres的复杂，MongoDB很简单、轻便，语法也很容易上手。此外，MongoDB很容易部署，因此第1、3和4条都符合得很好。然而，让我在MongoDB和PostgreSQL/GeoDjango纠结以至于一开始没有使用MongoDB的原因在于：Django对NoSQL没有支持！这意味着我不得不放弃近半数的Django功能，尤其是其引以为豪的后台生成器（admin generator）。这让人抓狂！ 最终，支持地理位置查询和快速开发的优点使我选择了MongoDB。 * * * * * [\[11\] ](#ac211)写这本书的时候，我很遗憾地发现everyblock已经关闭服务。其之前开源的源代码依旧可以在GitHub上查看：[https://github.com/brosner/everyblock_code](https://github.com/brosner/everyblock_code)。