oscarl's avatar

how to model this example with custom fields

Hi,

Im with a doubt about how to model the context below.

There is a entity "Conference" that can have 1 or more registration types(ex: general, vip). For each registration type there is a form that have always 2 mandatory fields: name and email. But then for each registration type the user that creates a conference can add more fields to the form. This fields can be of type: checkbox, input, select, textarea, date and upload file. And the conference creator can select each extra field as mandatory or not.

Example: A user create a conference and define 2 registration types. For one registration type its only necessary the default name and email of the participant. But for the other registration type the user add two extra fields to that specific registration type form. For this the user selects the type of field(checkbox, input, select, textarea, date and upload file), introduces the label for the field and selects if the field is mandatory or not. And do the same for the other extra field.

Do you know how this can be properly modeled? For now I have just the schema below:

Entities identified: Conference, RegistrationType, Form, FormField, FieldValue

Relationships:

1 to many relationship from Conference To Registration type (non-identifying)
1 to many relationship from RegistrationType to Form  (non-identifying)
1 to many relationship from Form to Field  (non-identifying)
1 to many relationship Field Form to FieldValue  (non-identifying)

Schema:

- Conference: ConferenceID, Name, etc
- RegistrationType: RegistrationTypeID, Name, Description, etc, ConferenceConferenceID
- Form: idForm, RegistrationTypeRegistrationTypeID
 - Field: idField, FormFormID, label, mandatory
 - FieldValue: idFieldValue, value, FieldFieldiD
0 likes
7 replies
robrogers3's avatar

I'm wondering if you can take advantage of json encoding for Form Inputs and their associated values.

Essentially, I don't think you need to normalize this at all, and you won't be querying for a fieldType or fieldValue.

this makes your required Models go down from 5 to 3. and will likely speed up your site.

defining and pulling out json is trivial. well automatic.

https://laravel.com/docs/5.5/eloquent-mutators#array-and-json-casting

you then just store your form field definitions as text. done.

2 likes
oscarl's avatar

Thanks,

So if I understand, we can have each field and respective value stored in json to the db. And a conference has one ore multiple registration types and each registration type has a form. So the 3 entities that you are saying should be Conference, RegistrationType and Form right? But then where to store the json information? In the Form table using just a attribute like for example "FieldsValues" is enough? Like:

  • Conference: ConferenceID, Name, etc
  • RegistrationType: RegistrationTypeID, Name, Description, etc, ConferenceConferenceID
  • Form: idForm, RegistrationTypeRegistrationTypeID, FieldsValues
martinbean's avatar

@oscarl I’d have your Conference model, which has many RegistrationType models, and each of those models can have many RegistrationQuestion models. They’re then be a pivot table in between RegistrationType and RegistationQuestion where you can store the answer:

  • registration_type_id (foreign key)
  • registration_question_id (foreign key)
  • answer (string)
1 like
oscarl's avatar

Thanks for your answer. In the RegistrationQuestion model the registration_question_id is the primary key not the foreign key right? And it seems ok a registration type can have many registration questions. But can you give a example of how a value of the field "answer" would be? Because Im not understanding how only this field "answer" can store the default fields (name, email) and the extra fields that the user can add, and also if each extra field is mandatory or not, for each registration type.

oscarl's avatar

For example in the registration page, the user do one registration in one registration type "general" and two registrations in a registration type "VIP". For the registration type "general" the user just needs to fill the default fields (name and email). But for the registration type "vip" the user needs to field the default fields but also an extra mandatory text field "phone number". How the answer field would store this?

robrogers3's avatar

@oscarl to answer your quest above. Yes. But I would name the column 'fields'

ps. recent versions of mysql support the json data type https://dev.mysql.com/doc/refman/5.7/en/json.html

ps. what's an answer. and how does that relate to this.

Also, you may want an another column for 'required_fields'. This is also json. It allows you to separate the custom and required, so that users can't clobber required.

Or just (and maybe better) create a custom accessor getAttributRequiredFields where you'd return an array of those two fields. Why monkey with the db for this?

1 like
oscarl's avatar

Thanks again for the answer.

So the db schema would consist in 3 entities/models:

Conference: ConferenceID, Name, etc

RegistrationType: registrationTypeID, name, description, conferenceID

Form: idForm, registrationTypeID, fields , requiredFields

And the fields column will have values stored like:

{"name": "value", "email": "[email protected]", "phoneNumber": "0000", "zip code": "000000"}

And the requiredFields:

{"name": "required", "email": "required", "phoneNumber": "required", "zip code":"optional"}

Right?

Please or to participate in this conversation.