ZODB or SQL ?

Plone 的潛在用戶在評估採用時，最大的猶豫之一，來自對 Zope Object Databse (ZODB) 的不熟悉，希望既有的 SQL Database 能夠繼續主導全局，如果初期評估 Plone 跟後期動手整合的人員是兩批不同人馬，這項疑慮與不安尤其明顯。終究，新的東西會帶來變動和風險，留在熟悉的範圍裡是多數人的自然反應。

文件 Zope/ZODB FAQ for IT Administrators 試圖提供說明和方法，讓上述的疑慮和不安能夠降到最低。

RDBMS 適合處理大量同質資料的場合，例如總帳系統使用關連式資料庫就很有效，但在表單格式變動大的情況下就受到限制。

ZODB 能讓開發者專注在資料模型的設計上，物件導向資料庫能在背景自動處理物件儲存的動作。在 class 的 method 改變時，並不會造成物件資料庫的困擾，當 attribute 修改時，等同於 relational schema 的修改，此時就要撰寫 migration 程式。

常見的需求之一，是把舊有的 SQL 資料交由 Plone 整合顯示，這並不難，利用 ZSQL Method 就能搞定最主要的工作。另外還可以試看看 RelStorage 能否處理未盡事宜。

ZODB 本身的執行效能，僅管不是最頂尖，應付一般場合卻已足夠。好吧，實驗數據看起來還不錯，但，很多人的實務經驗，還是覺得使用 ZODB 的 Plone 跑得很慢，該怎麼辦?

由於 Plone 以低階的企業級應用為場景，預設已納入群組權限、工作流程、版本控制等管理機制，多數的耗時運算，來自於安全權限的檢查，為了滿足 Plone 既有的胃口，最好先提供 1G 或 2G 的記憶體。