It would really depend. How are you intending to relate the models? And what kind of information would you need to keep for each request.

If the forms have a lot of information that is the same, you could keep that in one table and then add tables for the no duplicated data required. This probably is the neatest approach really. It terms of models, you could then relate these tables so that you tie in the info.

You may also want to take a look at Polymorphic relationships as it potentially could be the right way for you to go... http://laravel.com/docs/4.2/eloquent#polymorphic-relations

It is a difficult one to answer without getting deeper into the project and where you see it being expanded - future proofing is obviously key.

We recently built a similar system for a client and had a calendar model that had users_id, then holiday (vacation) requests with user_id and a job board to post available times slots to be filled where other staff could put there name forward. The last model was basically a pivot table of holidays and calendar.

My gut, not knowing your project properly, would be to keep them separate. Neat and tidy. Easy to add additional columns and additional tables and relationships as needed.

Hope it helps.

Basic Tables users, Departments, Vacations no need for submissions table (Just put a status column on vacations table(submitted,pending,approved, cancel) Relationship(users->hasOne Department , Departments->hasMany Users, Vacation ->belongsTo User and Users->hasMany vacations.

It will get complicated by adding permissions and roles table.

Thanks for your input guys, I know the question may have been a bit ambiguous.

T2theC said:

It would really depend. How are you intending to relate the models? And what kind of information would you need to keep for each request.

If the forms have a lot of information that is the same, you could keep that in one table and then add tables for the no duplicated data required. This probably is the neatest approach really. It terms of models, you could then relate these tables so that you tie in the info.

Each form would be asking for unique data. For instance, vacation requests will have dates, reasoning, etc., while a shift change form will have a complete different set of data.

I was thinking of using a Submission model that will act more like a pivot table. Where you store the Submission ID, Submitter ID, Form Type and Status. What I would do is, when a form is submitted, it populates the Submission table with that information, then by using the Submission ID and Form Type, relate it to another table just for that form (where it will hold the form specific data).

My hope would be when I want to retrieve all a user's submissions, I can query just the Submissions table and it will pull in the related table's records.

Does that make any sense?