UNDO/REDO в БД

[MaxFm536]

Всем добрый вечер.
Хотел вот такой вопрос задать: существует ли вообще технология UNDO/REDO в базах данных и если есть то какой основной принцип. Мне просто не совсем понятно.
Ну вот если всего один пользователь редактирует БД то тут никаких вопросов нет.
А если пользователей много.
Ну предположим: один юзер изменил одну запись 10 раз. это все записалось в таблицу tbackup. Затем юзер ушел курить бамбук на 3 часа и за это время эту запись изменили 10 юзеров по 10 раз. Все это тоже
Тут пришел наш первый юзер и решил отменить последнее изменение. Тут вопрос - какое оно будет??? те изменения что он делал - тогда пропадут те 100 узменений что делали другие юзеры. или то что сделалось последнее над данной записью, т.е. не то что сделал другой юзер. Тогда история undo/redo нашего первого юзера будет неправильная?!!!
Как тут правильно быть? или существуют другие правила?!!

[soleil@mmc]

обычно юзеру такие вещи не доверяются
все откаты и перенакаты изменений данных делаются админом базы
и все это верно если на уровне конкретной таблицы разработчиком не реализована версионность данных, т.е. хранение всех предыдущих версий измененных данных

[MaxFm536]

Сообщение от soleil@mmc

обычно юзеру такие вещи не доверяются
все откаты и перенакаты изменений данных делаются админом базы
и все это верно если на уровне конкретной таблицы разработчиком не реализована версионность данных, т.е. хранение всех предыдущих версий измененных данных

Ага , то есть сами по себе кнопки UNDO/REDO обычному пользователю недоступны. просто все изменения базы хранятся в лог- и backup-таблицах
и если юэер понял что накосячил то тогда приходит с презентом к админу и тот вертает все в зад?!!!!:

[soleil@mmc]

это смотря какой админ и как он настраивал архив/редо/и т.п.-логи
+ смотря про какую субд речь

[MaxFm536]

БД - SQL Server200 или SQL Express 2005, еще окончательно не определились.
Просто в тех.задании написано требование о реализации технологии
UnDO\REDO. А я вот понятия не имею как ее можно создать с многопользовательским источником данных (БД)

[BARNEY]

MaxFm536
делай всё триггерами... при update записи копия её идёт в таблицу log и всё... надо будет вернуть от туда и достанешь . таблицу чисти раз в N раз, смотря от количества записей и объёма БД.

[MaxFm536]

BARNEY как уже реализовывать эту технологию это уже второй вопрос. Мне был важен принцип - из всего я понял что данная технология разрешена только администратору. Юзер самолично не может восстановить запись. Только через админа

[soleil@mmc]

Сообщение от MaxFm536

BARNEY как уже реализовывать эту технологию это уже второй вопрос. Мне был важен принцип - из всего я понял что данная технология разрешена только администратору. Юзер самолично не может восстановить запись. Только через админа

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