Is Plone suitable for a project with strong database management requirements?
Plone User List: Ben Lobo 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. Ben Lobo asked how he can use Plone. Martin Aspeli answered about database management in Plone.
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).
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.
tags: | |