I'm in the need to write some PHP code to create and handle generic form inputs. This means an administrator from a backend should be able to create a list of forms, that have N fields of any type.
The users then will compile ONCE the different forms (for example one for could be user data and another for a questionnaire).
My idea is to create 3 separate tables as follows :
Table Forms
Form_ID
Form Name
Action
...
Table FormFieldsDescr
Field_ID
Form_ID
Label
Type
...
Table FormAnswers
Answer_ID
User_ID
Field_ID
Value
...
This way the form and fields structure will be stored in the first two tables. In a separate table I'll store the single answers from the users, being able to reconstruct the whole structure at the moment of consulting the answers.
Is there a better way to store generic structured forms into a database?
Related
I am uncertain of the best way to store multiple select options into mysql. Initially, I created a comma separated list of selected values. I have read that this is bad programming practice and also had a difficult time trying to figure out how to search the three columns in my db with the comma separated varchar value (eg: 1,5,17). It seems the best practice would be to create a 3rd table that would insert 3 records for the example above. This table would be linked via an id.
Example:
Table 1 (age levels)has fields id & age level (baby,teenager,adult)
Table 2 has classes id & class name
Table 3 is to store the multiple select options of WHO can attend each class. I guess the fields would be id & classID & ageLevelID
My questions are as follows:
1. how do I efficiently insert this data into table 2 and table 3?
2. how do I pull it all together to search for a person who is looking for a class that allows for just babies and teenagers, for example?
Relating 2 tables is easy, relating 3 tables is a conceptual struggle. Also, am I correct that it is asking for trouble to store comma delimited values in one field? Thank you.
Table agelevel (ageid (unique), agelevel)
Table classes (classid (unique), classname)
Table classesinfo (classid, fieldname,fieldvalue)
With that you could have any 'fieldname' such as agelevel, detailed description, hours, etc and then the value of that field in fieldvalue. This allows your classes to any an infinite number variables attached to a single classid.
I have a semi-complex database with multiple tables (3) that I'd like to post data to.
Rules of database
Each experiment (experiment table) can have multiple varibles associated with it (1 to many)
Each variable (variable table) can have multiple values (value table) (1 to many).
Sample DB Structure
experiment table
exprid (pk - auto_increment)
pagetype
pagename
expresult
variable table
varid (pk - auto_increment)
image
varresult
exprid (fk)
value table
valueid (pk - auto_increment)
image
valueresult
varid (fk)
I'm setting up a form that accepts inputs that will post to the appropriate tables, however I am having a hard time understanding how I can get this to work properly.
Here's essentially what I'd like to do:
User enters experiment details
User enters details for variable 1 (that info is associated with the experiment)
User enters details for value 1 (that info is associated with variable 1)
user submits value 1 to value table
User enters details for value 2 (that info is associated with variable 1)
user submits value 2 to value table
user is finished entering values for variable 1
User creates new variable in order to enter new values
Repeat steps 2-6
Ultimately, I am unsure how to:
a) post to the appropriate tables
b) ensure the visitor does not have to enter the experiment details once a value or variable is submitted
The ask:
It would be great if someone can help me understand the logic that goes into something like this. I really don't even know where to start because all of the forms I've built so far require me to only post to 1 table. So written logic would be helpful.
Any links to posts about this topic or articles online, any instructions on how to tackle or even sample code would be helpful. At this point, I think anything would be helpful if I can just get an idea of where to start.
So after each submit (via ajax request) you have to extend your list of fields.
If you're using jQuery I would suggest to have a look at it's ajax methods: http://api.jquery.com/jQuery.ajax/
When the data is submitted dynamically add your fields, there are dozens of tutorials, like: http://www.infotuts.com/dynamically-add-input-fields-to-form-jquery/
That's all, so in the end you'll have multiple requests which always store your new added data and skip the reload of the pages, as ajax is done in the background.
I'm working on an app that lets a user create projects custom to the users needs, the project is basically a form that can be submitted by another user.
I want to allow the user to dynamically create new fields (with Javascript) to the project (a basic form) and choose custom values for each field.
And when the project (the form) is ready it can be submitted and the user specified values goes to a database. Then another user can submit the form and the values the original user has chosen are as options for that form.
The values (that are dynamically created by the user) are most likely going to be basic data, like name, phone, email etc. But there is also options for specific data like food, address, etc. I want the user to be able to ask for any data he/she sees necessary.
So how should I structure my database? I cannot be sure what or how many fields the user is going to choose for his project, i was thinking of doing this app in a traditional relational database, most likely Postgres or Mysql.
So should a create columns for all the data I can think of (or allow user to create) or could this be done in some other way?
You may want to take a look at the EAV model. It has some pros as you will have some flexibility to create whatever structure you want, but it has also some limitations on retrieving and querying afterwards.
Your database should contain the following columns in the table for the form specs:
name (name of the field, used as "name" attrubute of the form's input field)
label (Description to print in the form)
format (if you want to distinguish selects/inputs/checkboxes)
validation (if you want a set of validation rules)
value_type (int/string/date/etc.. - type of value to accept from user. helpful for validation)
I ran into a similar situation with an assessment application. Each assessment asked a number of questions, but periodically, the question set would change. Rather than creating a separate table with key/value pairs for the questions and answers, I took advantage of serializing in PHP.
Determine what data must be a part of every form (Id, submitter, submission datetime, name of project, phone) Make those data elements columns in your table.
Create an additional column for the serialized data. This is where you store the additional attributes.
(Only 1 table needed)
When it comes to displaying the form, use the serialized data to build the additional form elements that are needed.
With this model, it is difficult to search the additional data that gets stored in the serialized data, but it simplifies the development; with thousands of records, and over 100 'questions' per assessment, we haven't run into an issue yet.
One possible option:
table: inputs
Description: Stores different types of inputs (select, select multiple, input, checkbox, radio)
Fields: inputtypeid (primary), input_type, status
table: fields
Description: Stores individual fields that the project owner has created.
Fields: fieldid (primary), inputtypeid (ref inputs), label
table: values
Description: Stores values (default and user submitted) for fields.
Fields: valueid (primary), fieldid (ref fields), value, default (bool yes/no)
table: project_forms
Description: Stores a list of fields that apply to the project.
Fields: pfid (primary), projid (ref project), fieldid (ref inputs)
One side note here. Make sure you take care not to let users store personally identifiable information into something like this. Or if you do, make sure you take the necessary precautions to safeguard that data, which is a bit different in this setup than in most cases.
I'll try to explain my problem and let´s see if I get some help.
I`m trying to design a DB. This data base will contain users and forms but my problem is how to design it to save forms.
The forms will be created by the administrator when he needs them, so in the DB I have a table to save the form name. Another table with all the possible fields for all the forms and another table where form-names and fields will be save so I can see all the field that a determinated form has.
An example: In FormName table I have 3 form names: Personal Info, Computer Knowledgement and hobbies. And in Fields table I have, for example, Name, Address, Phone, Operating Systems, Programming, Bike ridding, playing pc games.
I decide to create a form with name number 1 (Personal info) and fields number 1,2,3 (Name, Address, Phone). This information is recorded in another table called full-form where it´s saved form name id and field id. This is pretty clear for me (perhaps I´wrong).
The tricky part comes now. Some user decide to fill the personal info form so the name of the form and each field will has to displayed. When the user fill the form it has to be saved some way so the administrator can see the name of the form, each field that that form has, who filled the form and the information written in each field. And all this should be displayed not only in the DB but in some different way like a table, for example.
By the way... I´m using cakephp and mysql.
Thanks in advance,
Abraham
As far as I understand, setup looks like this. As you said, we have 3 tables:
'formname' = id, name (for form names)
'formfields' = id, fieldname, attributes (for form names, added attributes in case you need them)
'forms' = id, formname_id, formfields_id, formfields_order (ready forms and possibility to order field in form)
And also you should create additional table where to store submitted values
'forms_values' = id, forms_id, value (in this case one row for each field)
If you want to relate those values to specific user, one more table should be created
'users_forms' = forms_values_id, user_id
Of course there should be users table as well.
My suggestion is to drop table 'formnames' and put form name in 'forms' table.
Then table 'forms' will contain
id, form_name, formfields_id, formfields_order
Hope this answer will put you forward :)
I have read other answers on this (or at least near to this) subject but I couldn't get a clear view of it so I'm asking for help again.
I have a complex dynamic HTML form that I would like to submit to database using PHP. The form is split into multiple tabs and in each tab I got checkboxes that trigger other parts of the form. Example: at a point in my form I got a checkbox group that has options of: "hotel" and "restaurant". If I check hotels, I get another part of the form displayed, specific for "hotels". Same thing for "restaurant". So it's very dynamic here and I don't know which would be the best approach for storing every form field in database. Because it could contain 15 fields or 20, depending on the selection. Any example would be appreciated as I'm not that advanced with database design.
Thank you!
So it's very dynamic here and I don't
know which would be the best approach
for storing every form field in
database.
I apologise if I have misunderstood you here but I believe that you should design the database according to the data and not the form. It is difficult to comment without knowing the exact details of your situation so here is an example:
If you usually dump all the data from a form into a single table, but because sometimes this will involve submitting 5 values and other times this will involve submitting 10 and so you are unsure how many columns your table should have, then I think the problem is in the database design.
Work out what pieces of data are dependent on other pieces of data. For example, you mention checking "hotel" might open up more fields specific to that choice. Let's assume this involves things like "en-suite", "bed type" etc. Then you should have 3 tables, a registration table (assuming the user is using the form to buy these services), a hotel table and a registration_hotel table. The registration table will record a number of details specific to the registration only such as the customer's name and a unique id number. The hotel table will hold information specific to the hotel only, such as how many rooms have en-suite. The registration_hotel table will hold details specific to that registration at that hotel. You might want a column of type bool to record whether the user requested "en-suite".
When submitting the form, check which pieces the user entered with if(isset($_POST['hotel']) && !empty($_POST['hotel'])). Then only send stuff to the registration_hotel table if that condition is true.
If this design results in making too many separate calls to the database, you might want to look into transactions which will help you to manage the speed and security of these calls.
If you can post in a specific example of something you don't know how to do, that would be useful.
You didn't specify how you can manage this dynamic form. Can you edit it's PHP/HTML source? One great thing would be if you can label your different variables like hotel[], restaurant[], etc.
If your submitted form is clear enough (i mean semantically correctly structured) you can store the whole submitted form serialized.
Note: this method only working when you don't need to search for specific items in your database.
Edit: maybe i'm misunderstood your problem.
You can create a 'metadata' table like this:
form_id | option_name | option_value
---------------------------------------
1 | hotel | true
1 | restaurant | false