Is Plone suitable for a project with strong database management requirements?

Ben Lobo:

I've got a client who wants to develop a kind of work pool website where employers seeking skilled and/or manual labourers can search a database to find available workers.

This will involve enabling people seeking work to register on the site and, for a fee, add details of their skills, etc.

My inclination would be to develop this site in PHP and MySQL because that's where I've got most experience and I don't know enough about Plone and its database management capabilities to convince me that it would be as easy to manage and maintain the data as I know it would be in MySQL.

On the other hand, I really like the idea of using Plone because it's got the registration and membership side of things all covered and it's so easily extensible.

I'd like to hear anyone's opinions about whether or not Plone is suited for such a project (bearing in mind my limited Plone knowledge).

Martin Aspeli

There are a lot of issues here. I'll try to list some of them in bullet  form; feel free to reply on the list if you want more detail.

 - Zope/Plone is a very different model to PHP/MySQL. That means there  will be a learning curve, and you'll have to un-learn some of the things  you take for granted in PHP/MySQL.

 - However, ease code re-use, usability, the add-on products  (plone.org/products) and many other factors make Zope/Plone a powerful  platform that may help you get up and running *quickly* (if you can manage  the learning curve)

 - Zope is an object oriented system. You have content objects, organised  in a hierarchy of folder-like and document-like objects, inside the ZODB  (Zope Object Database). This is very good for storing unstructured or  loosely structured content. It's less ideal for storing a lot of  standardised data you want to cross-reference and analyse in different  ways. For this a relational database is probably better suited.

 - However, you can connect Zope to a relational database, including MySQL  and PostgreSQL. Look into ZSQL Methods for some information on this.

If it were me, I'd probably use Plone for the UI and member management,  turning off the things that didn't make sense, and store the jobseeker  data in PostgreSQL (or MySQL) and use ZSQL methods to analyse/match/query.  For the member management, CMFMember may be a good place to start. You can  use something like SQLWindowStorage or SharedSQLStorage to get the  standard member data to be stored in an SQL database instead of the ZODB  (I wrote SharedSQLStorage for a customer project where we had most  membership data in an SQL database, managed via CMFMember exactly in this  way). Then you can write some ZSQL methods to do the matching and some  page templates to display them.