NYCPHP Meetup

[Patrick May]

Hello,

On May 15, 2007, at 10:45 AM, Brian Dailey wrote:

> I have several large forms that I am putting together. I'm aiming  
> to keep them flexible and make it fit within the database object  
> schema that I have used so far in this particular program.
>
> In the past with a large form I've seen some developers resort to  
> tables with a multitude of columns... I thought that this was a  
> kludgy solution and I'd like to avoid it if possible. Another way  
> I've seen it handled is to have a header table and a detail table  
> that works something like this:
>
> table: documents (id, date, etc)
> table: documentdetails (documentid, fieldname, fieldvalue)
>
> All of the form values were stored in a fieldname=fieldvalue format  
> inside the table. This worked nicely until you attempted to run  
> reports on it - you couldn't easily combine data since it all  
> existed in different table rows.
>
> So, I humbly come before thee, o PHP gurus, and ask you, how would  
> you advise approaching this? Are there other ways to handle huge  
> forms? I have seen people serialize arrays and store them in a  
> column, but I can't see that working well when creating reports.
>
> I've googled and read around as much as I can on this one, but what  
> I need is some advice from some more experienced developers. Opinions?

My question is -- when the forms change, who makes the change?  You,  
or a user via a tool?

If you are making the change, then I would go with the flat table and  
make your code flexible.  It's nice to have a straightforward and  
flat table.  You can get your code pretty tight.  This is can be most  
problem anyways -- If you have a giant form, you can spend forever  
fiddling with the html.

But if a user is the one making the change, then I would go with one  
of the aforementioned solutions -- store everything in yaml, or  
entity attribute value.  I prefer EAV.

Cheers,

Patrick