1

So we have a form that has multiple fields and our employees can select/deselect each field when creating the form so that only certain fields actually appear on the form when the user views them. Sometimes, our employees would like to include a field that is not in this list. What is the best way of implementing this functionality? Should I set aside a few columns as "custom" fields and have a new table that keeps track of additions of new fields and just join the two tables when I create the form? Would this be achievable in php/mysql or is it better to use a scripting language like python/ruby?

gta0004
  • 508
  • 4
  • 11
  • 29

1 Answers1

0

You can do this with php.

in your form:

<input name="form[]" type="text" />

In your php:

foreach($_POST['form'] as $formInput) { ... }

and in your database -- well, that's up to you, but I would do an x - y - z schema:

where x is the user's ID, or the foreign-key - y is what the input is supposed to be (email, addr, etc) -- and z is the actual value.

The only problem with that would be --- let's say you have required inputs a,b,&c --- and optional inputs d,e,&f --

if d&e are not required to input f, then the 'y' value of 'f' could be 4,5, or 6 -- so, it gets a little trickier in the database side, depending on what exactly you're doing...

Alternatively, if you had JavaScript or jQuery adding the inputs to your form, then you could give them a name, and in your php, modify your query accordingly--- and just leave the columns blank if there was no value set for them.

rm-vanda
  • 3,122
  • 3
  • 23
  • 34
  • Yes, As far as your database is concerned. EAV would be the best way to go... -- I always forget "EAV" -- albeit, I'm not sure if EAV specifies to use INT as your value-type or "y" column.. – rm-vanda Jan 27 '14 at 21:11
  • I have read like everywhere that EAV is really not the way to go and can cause some problems. It that not true, or does that really only apply to very large services? – gta0004 Jan 31 '14 at 16:44
  • While I am not familiar with the specifics of EAV -- this sort of database model is certainly the way to go: 1). Small tables are good; JOIN is your friend. 2). Separating data by how it is accessed has performance benefits, especially when your keys are INT. 3). This is especially a good thing, when it comes to large services. Where are you reading that EAV-like structures are not the way to go? The only downfall is that they aren't usually human readable - which is why we write code to interface with it for us... – rm-vanda Jan 31 '14 at 17:25
  • That one is actually saying the opposite... In your case, you are talking about adding columns dynamically, in which case an EAV-like schema is the way to go. "EAV allows columns to be added without DDL changes" – rm-vanda Jan 31 '14 at 18:55