Hi,

right now I am thinking about a problem with extendable models. To
explain this a bit, please think about a "jobs" table. This table has
some base columns like id, date, title, description and status. No
problem at all to build a model class with Zend_Db_Table and to build a
form with Zend_Form.

Now, there are a couple of clients which need to extend this "jobs"
table with custom columns. For example client A wants to add a location
and a requirements column and client B wants to add the salary and a
services column. When client A wants to create or edit a job, only the
base columns and "his" columns should be displayed in the form and the
data should be saved in the "jobs" table. This system should be as
flexible as possible and the site administrator should be able to add
columns for each client whenever he wants to.

My problem is now how to implement this with Zend_Db_Table and
Zend_Form. I think it is not such a good idea to add each column to the
"jobs" table because there could be hundreds of columns in future.

Another idea was to have one "additional" column of type "text" in
"jobs" with can hold a serialized array with the additional data for
each clients job. But then some of these extra fields will be needed for
selecting and sorting the jobs of each client, which will be almost
impossible when using a MySQL text column.

Then I was thinking of an extra table for each client, say "jobs_a" and
"jobs_b" which can be accessed and amended by the site administrator.
These extra tables could be joined with Zend_Db_Table and I could work
with merged Zend_Config objects to work with Zend_Form. But this will
result in a lot of tables in the database.

Does anybody have some suggestions how to handle this problem? Are there
any best practices or design patterns for this?

Thanks and best regards,

Ralf

Reply via email to