我主要考察的數據庫有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)。