Ведение таблицы истории для приложения PHP

Я хочу сохранить таблицу истории для своего приложения, чтобы отслеживать, какие поля были изменены пользователем.

Ниже представлена ​​структура моей таблицы bugs_history:

id, bugsid, userid, field_changed, old_value, new_value, created_on, created_by

Итак, мой вопрос, когда я обновлю свою форму и отправлю, как получить имя поля, которое было изменено вместе с старым значением и новым значением. И добавьте измененные изменения в приведенную выше таблицу истории.

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


mysql php codeigniter history
person Channaveer Hakari    schedule 25.05.2015    source источник
comment
stackoverflow.com/questions/3816839/ .. Вещь который вы ищете, называется аудитом   -  person Amar Agrawal    schedule 25.05.2015
comment
@Amar Не могли бы вы предложить какие-либо другие решения или ссылки ..   -  person Channaveer Hakari    schedule 25.05.2015
comment
как вы хотите это сделать? Вы хотите справиться с этим через PHP или через MySQL?   -  person Amar Agrawal    schedule 25.05.2015
comment
Я хотел бы пойти с php   -  person Channaveer Hakari    schedule 25.05.2015
comment
В любом случае, когда вы обновляете форму, вы можете получить ее из базы данных. Сохраните всю эту информацию в какой-либо переменной и перед вставкой в ​​базу данных новых значений сравните ее с предыдущими значениями и, соответственно, вставьте в bug_history . Аудит всегда будет иметь проблемы с производительностью, независимо от того, делаете ли вы это самостоятельно или с помощью какой-либо библиотеки. Так что не думайте, что то, что я вам предлагаю, неэффективно.   -  person Amar Agrawal    schedule 25.05.2015

Ответы (1)


arrow_upward
0
arrow_downward

Если вы знаете имена полей (у вас есть HTML-форма, содержащая их, поэтому вы, вероятно, знаете имена), создайте их список, который вы затем просматриваете, создавая новый запрос SELECT для получения old_value, а затем запрос INSERT для его сохранения. . Выбор будет упорядочен на created_on DESC и LIMIT 1.

Но я вижу здесь явную проблему: параллелизм. Что произойдет, если два пользователя попытаются отредактировать одну и ту же ошибку (с одним и тем же bugsid) одновременно? Они ожидают, что old_value будет одинаковым для обоих? Или две операции должны выполняться последовательно? Или следует предупредить последнего редактирующего, что он пытается редактировать устаревшие данные? Какой из них получит «последний» created_on? Вот это и есть ваша настоящая проблема, а не написание кода, генерирующего два SQL-запроса.

person Sergiu Paraschiv    schedule 25.05.2015
comment
Да, я согласен с вами... но если вы думаете таким образом, то многие веб-приложения не справляются с этим. Помимо проблемы параллелизма, не могли бы вы предложить мне какое-нибудь решение или ссылки для моей проблемы, я буду вам очень благодарен. - person Channaveer Hakari; 25.05.2015
comment
Но если вы этого не сделаете, то в конечном итоге вы попадете в беду. Очевидно, что большинство веб-приложений плохие. Большинство программистов плохие :) - person Sergiu Paraschiv; 25.05.2015
comment
Да, ваше право... так что, по вашему мнению, лучшее решение. Если я хочу продолжить работу с существующим кодом, какое решение вы мне предложите. - person Channaveer Hakari; 25.05.2015
comment
Вам действительно нужно old_value? Я так не думаю. Устранение этого решает проблему параллелизма аудита. Проблема параллелизма, связанная с тем, что два человека редактируют одно и то же, имеет несколько решений. Либо переводите элемент в режим редактирования, когда кто-то начинает редактирование, и запрещайте кому-либо еще редактировать, пока он не разблокирует его, либо при сохранении проверьте, что значение еще не изменилось. Если же уведомил и спросил, как действовать - перезаписать или сбросить. Вероятно, для этого вам понадобятся транзакции. - person Sergiu Paraschiv; 25.05.2015