Unless you neeed to perform queries on the different (partner-specific) parts of the submissions, there is no need to use different columns. I would imagine a single table containing fields submission_ID, partner_ID and submission_data, plus possibly other fields with a global (not partner-related) meaning. The data would be a blob in a structured format. You could optimize for parsing speed by choosing your own format or go with XML.
As to the modules, I would associate to each partner one or more modules, perhaps classes inheriting from some common superclasses. When retrieving and managing the submission, the partner-specific module would take care of converting the blob to an in-memory representation. Something analogous would happen when creating, serializing and storing the submission. The modules would be retrieved on-the-fly (with some caching mechanism in place) by either perl's standard file-based "require" system or by reading them from a DB.
As to the choice of putting perl code in a DB, it is not wrong and in many cases it's a very advisable choice. Consider that the everything engine powering PM does it. It lets you modularize your application and make it extensible in a clean way and makes online updates doable without the risks involved in messing with the application filesystem.
AntonioIn reply to Re: database design question
by abell
in thread database design question
by nop
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |