Веб интерфейс для MySQL, undo/redo

[Geol]

Веб интерфейс для MySQL, undo/redo

Проблема в следующем. Есть база данных по клиентам, к ней веб интерфейс, с помощью которого оператор осуществляет такие функции как добавлиние/удаление клиента, изменение лицевого счёта, изменение статуса и т.д. Каждое подобное действие вносит изменения в 4-6 таблиц БД. Поставили задачу в данном интерфейсе сделать нечто подобное кнопке undo. т.е. многоуровневый откат.
Я думаю решить задачу протоколируя в отдельной таблице каждый запрос UPDATE|INSERT|DELETE, а потом разбирать данные записи, но мне кажеться что это слишком накладно, т.к. перед каждым запросом прийдётся делать ещё миниум один (а то и два, старые данные ведь придётся сохранять). И ещё ведь redo наверняка потребуют...
Может есть способ лучше?

 

[HEm]

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

 

[Geol]

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

 

[HEm]

высказывалась мысль (обсуждали в ирц) насчет логирования на уровне БД но тут же возник такой момент, простой пример:

<[si]> Yurik как откатить UPDATE aa SET foo='bar' ?

(если хошь, могу скинуть логи обсуждения на мыло)

 

[Geol]

Ну да и я про это...
а логи скинь если не трудно

 

[Falc]

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

 

[Geol]

Я же говорил

Каждое подобное действие вносит изменения в 4-6 таблиц БД.

по моему мой вариант по рациональней, хотя с бэкапом проще

 

[Falc]

Originally posted by Geol
хотя с бэкапом проще

И самое главное надежнее.

 

[Falc]

Бекап можно еще зиповать если проблемы с местом на диске.

 

[Geol]

Перед КАЖДЫМ запросом быкапить 4-6 таблиц....
нет мрачно

 

[Falc]

Originally posted by Geol
Перед КАЖДЫМ запросом быкапить 4-6 таблиц....
нет мрачно

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

 

[Konstantin]

А что если вместо DELETE делать заполнение специального поля в базе. - то есть делать пометку на удаление.
На UPDATE старую строку помечать как удаленную, и создовать новую с измененными данными.
Плюс, для каждой операции делать лог операций с присвоением каждой операции кода, и в изменненных строках указывать код операции по изменению, чтобы можно было делать откат.
При этом конечно прийдеться использовать транзакции, чтобы база не становилась не согласованной, при работе нескольких пользователей и/или сбоях твое кода.

Еще вариант, использовать PostgreSQL и написать before-тригеры, которые будут описанные мной операции делать автоматически. При таком раскладе уменьшеться объем кода который нужно править в самом Web-приложении

 

[Yurik]

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

И самое главное надежнее.

если с базой работает 1 юзер - да. Если хотя бы 2 одновременно - все из перечисленных выше методов абсолютно бесполезны.
Откат возможно делать только на определенную точку времени.
А действия пользователей никак не undo
Вот к примеру
UPDATE t SET a=a+1

ИМХО частично релизовать начальную задачу поставленную Geol можно только через клиентскую организацию трансакции.
Все изменения накопляются в "интерфейсе клиента" (если это пхп - то сессии), делается undo/redo и только в самомо конце делаетя один необратимый COMMIT всех изменений.
А rollback измененной БД afaik невозможен по определению

 

[Geol]

если с базой работает 1 юзер - да. Если хотя бы 2 одновременно - все из перечисленных выше методов абсолютно бесполезны.
Откат возможно делать только на определенную точку времени.
А действия пользователей никак не undo

И к тому -же нужно менять изменённую запись а не всю таблицу, т.к. другие записи этой таблицы используются.
В общем остановился на своём-же варианте