Question

I have an interesting problem that I’ve been trying to simplify. I have a telecommunications client who has several sign-up forms – each representing a different program/offer. Each form is essentially the same, but some have form fields that others do not. As you can imagine, this is a nightmare both in the database and in the CRUD code.

Right now as it stands, each form is processed individually and goes into a dedicated MySQL table for each application form. So horrifically, each application has a separate CRUD code. I wish to defer to the experienced as to how to best handle this situation.

I thought about parsing the form elements into CSV. I’d define a schema of sorts that identifies the elements so the CRUD can easily work off one table. However this is an issue because sometimes these form elements change which can make it difficult to keep everything organized and clean. I also though about having a base form with standard elements, then forms that are requiring different elements would be stored elsewhere with some FK.

I’m really at a loss as to what I could do to make this easier. I hate having several tables for applications, and several CRUDs for processing…

TLDR; How can I best manage processing/storing several unique/rather large (20 so elements) forms in a database and implement CRUD on them.

Thanks for your time.

EDIT I also just thought about implementing JSON or XML which would define the form elements and accepted data types. This could be modified by the system, and upon saving, could generate a cached HTML form page and updated SQL code for each application. That way, I can solve the editing problem. However, based on this implementation, I’d still need several tables.

Answer 1

One way to accomplish this would to be to have a base table that defines just a few fields common to all the forms, including some kind of ID. Then you have a separate table that stores all of the rest of the form data by name and value for each form. In effect, you have an object number, and then a set of attribute names/values for each piece of data in the form.

CREATE TABLE submission {
    submission_id INT,
    creation_date DATETIME
};

CREATE TABLE submission_attributes {
    submission_id INT,
    attr_name VARCHAR(50),
    attr_value VARCHAR(255)
};

The trick here is to have a general-purpose hydration function that can turn any submission into a useful PHP object or array (whichever you prefer working with).

Since your database only deals in strings, your validation functions will need to be up to the task of knowing what is a valid submission and what isn’t. You won’t be able to depend on your database to reject invalid data.

Another approach is to use an object database. My favorite is MongoDB, which lets you store arbitrarily complex data as JSON, and even index/search by deeply-nested object attributes. But there are other tools that will get the job done, too.