Alternatively, use 1 table. Have a column on table such as: approved that takes a boolean value. If the value is 1, then it's approved, in that case, notify the user.

If value is 0, then it's declined, remove the row from the table.

EDIT: I didn't think that through entirely. I'd use what you've listed.

@riliwanrabo You don’t want to ‘duplicate’ your tables, as that means you have to duplicate every table you want to add peer-reviewing to.

Instead, consider storing “revisions” of rows. Each user has multiple rows. Every time they change something, a new row is created but has a column and value of say, approved = 0. Managers can set approved to 1 to approve the change. So to get the user’s latest profile, you just select the last record with approved = 1.

I use to think that way too, but after asking such question on dba stackexchange (http://dba.stackexchange.com/), I changed my architecture a bit. I would rather not make a duplicate table, but add a tinyint* field to the table, named adminApproved , Official or something like that.
When an employee would propose a change, a row would be added with that tinyint field at 0 (false) When an admin would approve it the field would be put from 0 (false) to 1 (true) , and the old row turned to 0 When an admin would reject, the row could be deleted.

you would have add this to your queries : ->where('adminApproved', '=', '1')

It seems like your table would get "messy", but this is apparently better than duplicating tables and "copy/pasitng" rows from one to the other.

good luck !

*Laravel seems to use tinyint when we want a boolean.

@Prez seems to answer what i requested.

Here is part of the scenerio:- @DPJack , @martinbean , @SteveBelanger

~> I am an admin and @Prez id my employee

~> @Prez decide to update his first_name, last_name, mid_name and email columns.

~> Those changes would be stored temporarily

~> After I get a notification of those changes I decide to approve or reject i.e revert or keep those changes respectively.

For now I go with @Prez who said i should have a column where I store those changed column as JSON, use the data to update when I approve then nullify or just nullify when I reject.

@Prez Hope I understood your suggestions.

@DPJack , @martinbean , @SteveBelanger Do you agree ?

cheers

I implemented basically this same functionality many years ago in basically the exact way you describe with a second table that was basically a copy of the original. When changes were approved I copied the data over to the original and if they were declined I would delete the pending data.

This turned out to most definitely be the wrong way of doing it and made that project a huge pain to work with and is the source of a seemingly never ending supply of bugs even to this day.

The method Prez describes sound much better and is what I would do if I had to build the same project again today. Hopefully this saves you some of the pain I've had to go through.

@spekkionu YeahI agree with @Prez I haven't implemented his suggestion yet but oh my it makes a whole lot of sense. As soon as I apply it i tick it as the right answer

Jeffery did a video few months ago about this. Laravel has some built it features that makes it quite easy. That way your only storing some of the data, just what's been changed, in a Json object so it's ver dynamic and can be implemented as polymorphic for many tables later if needed.

https://laracasts.com/series/eloquent-techniques/episodes/2

Laravel 5.5 onward we have this package called [eloquent-approval] (https://github.com/mtvs/eloquent-approval) for maker-checker or review-approval kind of setup.