The Symfony CMF Book

RDBMS
Looking at the above requirements it becomes apparent that out the box an RDBMS is ill-suited to
address the needs of a CMS. RDBMS were never intended to store tree structures of unstructured content.
Really the only requirement RDBMS cover from the above list is the ability to store content, some way
to reference content, keep multiple separate content structures and a basic level of access controls and
triggers.
This is not a failing of RDBMS in the sense that they were simply designed for a different use case: the
ability to store, manipulate and aggregate structured data. This makes them ideal for storing inventory
and orders.
That is not to say that it is impossible to build a system on top of an RDBMS that addresses more or
even all of the above topics. Some RDBMS natively support recursive queries, which can be useful for
retrieving tree structures. Even if such native support is missing, there are algorithms like materialized
path and nested sets that can enable efficient storage and retrieval of tree structures for different use cases.
The point is however that these all require algorithms and code on top of an RDBMS which also tightly
bind your business logic to a particular RDBMS and/or algorithm even if some of them can be abstracted.
So again using an ORM one could create a pluggable system for managing tree structures with different
algorithms which prevent binding the business logic of the CMS to a particular algorithm.
However it should be said once more, that all Bundles and Components in the CMF are developed
to enable any persistent storage API and we welcome contributions for adding implementations for
other storage systems. So for example CMF RoutingBundle currently only provides Document classes for
PHPCR ODM, but the interfaces defined in the Routing component are storage agnostic and we would
accept a contribution to add Doctrine ORM support.
PHPCR
PHPCR 3 essentially is a set of interfaces addressing most of the requirements from the above list. This
means that PHPCR is totally storage agnostic in the sense that it is possible to really put any persistence
solution behind PHPCR. So in the same way as an ORM can support different tree storage algorithms
via some plugin, PHPCR aims to provide an API for the entire breath of CMS needs, therefore cleanly
separating the entire business logic of your CMS from the persistence choice. As a matter of fact the only
feature above not natively supported by PHPCR is support for translations.
Thanks to the availability of several PHPCR implementations supporting various kinds of persistence
choices, creating a CMS on top of PHPCR means that end users are enabled to pick and choose what
works best for them, their available resources, their expertise and their scalability requirements.
So for the simplest use cases there is for example a Doctrine DBAL based solution provided by the
Jackalope 4 PHPCR implementation that can use the SQLite RDBMS shipped with PHP itself. At the other
end of the spectrum Jackalope also supports Jackrabbit 5 which supports clustering and can efficiently
handle data into the hundreds of gigabytes. By default Jackrabbit simply uses the file system for
persistence, but it can also use an RDBMS. However future versions will support MongoDB and support
for other NoSQL solutions like CouchDB or Cassandra is entirely possible. Again, switching the
persistence solution would require no code changes as the business logic is only bound to the PHPCR
interfaces.
Please see installing-configuring-doctrine-phpcr-odm for more details on the available PHPCR
implementations and their requirements and how to setup Symfony2 with one of them.
3. http://phpcr.github.com
4. https://github.com/jackalope/jackalope
5. http://jackrabbit.apache.org
PDF brought to you by
generated on June 13, 2013
Chapter 6: Choosing a Storage Layer | 26