Один человек редактирует данные, в базу отправляются запросы, человек видит результат сразу.
Второй человек проверяет что сделал первый человек, и подтверждает или отклоняет изменения.

Как такое реализовать бы?

База MySQL если это важно

1-й изменяет данные в одной таблице, второй подтверждает, тогда процедура переносит данные в основную таблицу, нет - замещает из основной неизменными или просто удаляет данные в первой

(0) Использовать версионность записей.
Дальнейшая логика зависит от политики обработки. Например, если новые данные должны быть доступны сразу, то последующее "утверждение" сводится к удалению всех поколений кроме нужного. "Отклонение" - к удалению временного поколения.
Или разнос по разным таблицам, как в (2)

(3) только ничего штатного для версионности в mysql вроде нет. Так что придется ее изобрести. Или может я ошибаюсь

Вот интересная статейка https://habrahabr.ru/post/136202/

как отправная точка для осмысливания. Есть там еще ряд интересных комментариев.

А так дай больше подробностей, какие данные нужно версионировать. Я пока понимаю, что нужно некое подобие премодерации изменений на сайте?

(2) Если использовать вторую таблицу, то не понятно что делать если вдруг возникнет такая ситуация: Одно изменение отклонили, следующее изменение связано с отклоненным и без него будет ошибочным. Как такое отследить и не дать накатывать конфликтующие изменения?

(3) Я не совсем поннимаю что значит версионность записей.

(3) А, понял. То есть если мне нужно отклонить какое-то изменение, то все изменения сделанные после него тоже отклонятся? Таким образом избегаем конфликтов.
Но это не подходит, потому что последующие изменения не все нужно отменить.

(4) Данные - это каталог клиентов. Их нужно редактировать, удалять, переносить в категории, объединять дубли (вместе с их подчиненными элементами)

(7) Введи сущность "изменение", возможно синтетическую. Идентификатор этой сущности будет версией записи.

(9) Опять таки не понятно как отследить взаимосвязанные изменения которые нельзя отклонять по отдельности, а можно только вместе.

(10) начни с более точной постановки задачи, далеко не всегда, отклонив более раннее изменение возможно сохранить более позднее ввиду разрушения взаимосвязей. Может лучше модерацию изменений проводить в обратном порядке: если тебя устраивает самая новая версия, то зачем тебе сдались промежутки?

(11) Как раз если устраивает самая новая версия то проблем никаких нет.
Плохое начинается когда она не устраивает по причине какого-то изменения которое далеко не последнее.

(12) значит отбрасываешь последнюю и переходишь к предпоследней и так далее

(13) И все нужные изменения оказываются выброшены. Это плохо. Писал уже в (7).

(10) Взаимосвязанные изменения будут иметь одинаковый идентификатор. Все модификации таблицы сводятся к добавлению записей с нужной версией. Ну, еще флаг удаления придется сделать - или прямо в таблице или в сущности "изменение". Которое как раз является предметом "утверждения" или "отклонения".

(14) как это нужные выброшены? если самая новая редакция не нужна и ты ее отбросил и перешел к предпоследней, что в данном случае выброшено нужного?

(15) Осталось придумать как присваивать одинаковый идентификатор взаимосвязанным изменениям. Точнее, как вычислить что изменения взаимосвязаны. Если это вычислить нельзя, и другим способом задачу решить нельзя, тогда задача не решаема.

(16) Не то чтобы вся новая редакция не нужна. Она нужна, но не вся. Частично. За вычетом не нужных изменений.

(18) то есть версионировать нужно тебе не весь объект в целом, а его реквизиты скажем так?

(17) Кажется, ты путаешь понятия "изменения" и "версия". Оперировать надо не изменениями в состоянии от версии к версии, а "срезом". Записывай все изменения при "утверждении" одной транзакцией с одним идентификатором.

Вы кажется не поняли. Объясню на пальцах:

Оператор удалил клиента "ООО Винторг"
Оператор объединил клиента "ООО Варадат" и "Варадат ООО"

Проверяющий решил что "удалять" того клиента не нужно и отменил это изменение, но при этом "объединение" одобрил и оставил.

По вашему же получается что проверяющий отменяет все изменения как "удаление" так и "объединение", а это не подходит.

(21) Значит у тебя, согласно твоей теории об утверждениях и отклонениях было два изменения, а не одно Одно удаление, второе - объединение. Одно утверждено, второе - отклонено.

(22) Конечно. Я так и написал

(23) Тогда еще раз и медленно.

У тебя. Было. Два. Изменения. Значит. В базе появится. Два. Идентификатора "среза" или "версии". Записи. По каждому. Из них. Можно. Утвердить - оставить. Или удалить - отклонить.

(24) Все верно, я так и написал.

(25) Ок. Тогда можешь приступать.

(26) как только найду ответ на свой вопрос

(21) клиент винторг это один элемен его и версионируй

варадат - это другой. Зачем смешивать 2 независимых элемента в версионировании между собой?  Версии существуют только в зоне одного элемента БД, и если ты отклонил версию первого, то причем тут второй, они ни коим образом не должны быть связаны

(28) "ООО Варадат" и "Варадат ООО" - это один объект или разные? У них еще подчиненные элементы справочника торговых точек имеются.

(29) это 2 объекта, которые станут одним. И пока не будет подтверждения, второй из базы физически не удаляется. Все подчиненные тоже обрабатываешь в при изменении и версионируешь независимо, при откате также выбираешь и откатываешь. Каждый в отдельности.

(30) Так не подойдет. Оператор должен видеть результат сразу, иначе запутается что сделал, а что нет.

(31) какой результат? он видит что объединены 2 элемента, видеть подчиненные ему не надо, их нужно обрабатывать на программном уровне. То есть оператору ты показываешь только объекты инициаторы, объекты измененные программно не показываешь