This is a space to draft a one-page FAQ for eventual publishing on plone.org.

The problem this document is intended to solve

For some potential Plone customers, such as universities and larger companies, a significant barrier to adopting Plone can be resistance from IT departments to the Zope Object Database (ZODB). This is especially common when the team responsible for hosting a Plone deployment is separate from the team responsible for the initial Plone implementation. Most of these objections trace back to the fact that the ZODB is unfamiliar, and the natural tendency of people to resist or exaggerate unknown risks.

This document is therefore intended to provide reassuring facts about the ZODB that Plone advocates can use to overcome potential objections from those who argue that Plone's ZODB backend is too different, unfamiliar and/or risky to deploy.

This document is intended to be structured as a FAQ, with a brief narrative introduction. It should be written in clear, straightforward language that will be understandable by IT decisionmakers who are unfamiliar with Plone. It should be positive in tone, factual, authoritative, and free from hyperbole or unsupported opinion. Please provide links/references to supporting documents whenever possible.

Introduction: The Zope Object Database: Simple, Stable and Scalable

Plone's database backend is the the Zope Object Database, aka "the ZODB." The ZODB is an object database system, ideally suited for the data storage needs of enterprise-quality CMS products like Plone. The ZODB is easy to maintain, extremely stable and reliable, and easy to scale via replication and clustering.

Because the ZODB is an object database, rather than a relational database, it is extremely well-suited to storing the kinds of content that most websites produce -- hierarchical content with lots of different data schemas. Because the ZODB is not a relational SQL database, it is immune to common security problems like SQL injection attacks. The ZODB's transactional nature means that it is resistant to data corruption and instability. And, best of all, because it doesn't have tables or schemas, the ZODB requires minimal maintenance from an IT team, other than routine backups and packing, which can be performed via simple shell scripts.

Frequently Asked Questions about the ZODB

Is the ZODB a relational database? Does it use SQL?

The ZODB is not a relational database. It does not use SQL.

A relational database is organized as tables of columnar data. The tables are interrelated by one or more columns of data which are repeated in separate tables. SQL is a language used to select data from one or more tables at once by specifying patterns of desired data between interrelated tables.

The ZODB is an object database. Objects are bundles of data organized in patterns which can be much more representative of real world relationships than columnar data. Some of the data in objects can be behaviors which act upon the data in an object, so that an object tends to be a self-contained bundle of data which "knows" how to process itself.

Python is the query language for the ZODB. Python is a popular object oriented programming language. Everything in Python is an object. A ZODB is simply a place to "persist" Python objects.

The objects in a ZODB are organized like a tree springing from a common root, just as objects are organized in object oriented applications. This tree is called an "object hierarchy," which means that object databases belong to a class of databases known as hierarchical databases. The difference between an object database and prior conceptions of hierarchical databases is that objects have behaviors and know how to process themselves.

The advantages of object databases over relational databases are amplified in web applications. All modern web applications are object oriented, as is the web itself. Web applications which rely on relational databases must spend resources translating objects from the programming lanaguage in which the application is implemented into tables in a database, and vice versa. This is called "Object to Relation Mapping" or ORM. Developers of web applications backed by relational databases tend to spend a great deal of effort on ORM activities. The development of many web applications is often hampered by the bad fit of forcing real world data modeled by objects into interrelated groups of tables, causing performance bottlenecks.

Developers of ZODB application use Python to simply specify the "path" to an object in the hierarchy of objects stored in a ZODB. The ZODB transparently handles the creation of objects in the application from the ZODB storage, and the persistence of objects from the application in the ZODB storage.

The ZODB is simply a way of persisting objects. The ZODB can be backed by any number of different storage mechanisms. The simplest and most maintainable is a single file containing all the objects. Another storage divides the object tree into branches, storing each branch in a separate file called a "mount point." Yet another storage is a hierarchy of files and directories, one file per object, with the directories structured like the tree of the object hierarchy.

If a relational database is an institutional must for data storage, the ZODB can be backed by a relational database for storage. The ZODB is still queried using Python. Tables within the relational database then will contain "serialized" objects instead of mapped data. ZODB mount points can also store some branches of the object hierarchy in a relational database and other branches in other storage mechanisms.

What maintenance does the ZODB require?

Answer here.

Do I need any special Zope-specific knowledge to administer the ZODB?

Answer here.

How secure is the ZODB?

Answer here.

How do I scale and replicate the ZODB?

Answer here.

How do I import/export data into the ZODB?

Answer here.

Can I use a relational database backend for Plone instead of the ZODB? Will this let me query the ZODB with SQL?

The ZODB can use a relational database backend for storage, via RelStorage. RelStorage supports MySQL, PostgreSQL and Oracle RDBMS backends. However, using RelStorage does not gprovide the ability to query the ZODB with SQL. Like other ZODB storage implementations, RelStorage stores data as pickles, making it hard for anything but ZODB to interpret the data. An earlier project called Ape attempted to store data in a truly relational way, but it turned out that Ape worked too much against ZODB principles and therefore could not be made reliable enough for production use.

Can Plone interact with data I already have in a relational database?

Plone can easily read and write data stored in relational database systems.

Useful reference material

Jim Fulton presentation about ZODB (very technical)

http://www.python.org/workshops/2000-01/proceedings/papers/fulton/zodb3.html

IBM Article that Explains ZODB and its benefits

http://www.ibm.com/developerworks/aix/library/au-zodb/