Форум MySQL

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

Как
проще вести логи исправлений этих таблиц, чтобы потом легко можно было откатить исправления внесённые тем или иным посетителем, отталкиваясь от его ID и даты?

Хотелось бы решение в рамках MySQL. На триггерах, например.
Трудность в том, что если для каждой из 5 таблиц писать по 3 триггера (INSERT, UPDATE, DELETE), то получается работы на неделю.
Возможно ли написать три универсальных триггера для логирования любых таблиц?

>Есть несколько таблиц, которые доступны для редактирования через интерфейс всем зарегистрированым посетителям.
>Однако содержимое таблиц критично для работы сайта (если в таблицах будут ошибки, то сайт не будет работать правильно)
>
>Как
>проще вести логи исправлений этих таблиц, чтобы потом легко можно было откатить исправления внесённые тем или иным посетителем, отталкиваясь от его ID и даты?

Как вести логи, или как проще вести логи?


>Хотелось бы решение в рамках MySQL. На триггерах, например.

У Вас есть хоть какое-то решение, чтобы можно было говорить об оптимизации, или нет никакого?

>Трудность в том, что если для каждой из 5 таблиц писать по 3 триггера (INSERT, UPDATE, DELETE), то получается работы на неделю.

А в чем принципиальная проблема?

>Возможно ли написать три универсальных триггера для логирования любых таблиц?

То есть триггеры для конкретной таблицы Вы уже написали?

Лентяй.

Я впервые сталкиваюсь с задачей отката сделанных кем-то исправлений.
И не могу пока сориентироваться с какой стороны к ней подступаться-то, чтобы она не вылилась в нечто непомерное
==============================
Ещё точнее, у меня постепенно формируется нечто вроде собственного фреймворка, на основе которого можно многое писать значительно быстрей.
Вот мне и хотелось бы максимально универсальное решение для отката таблиц.
Тем более, что даже только лишь в данном задании мне надо заботиться об откате нескольких таблиц. Нечто универсальное само напрашивается.

Но для того определиться, в каком направлении искать решение, опыта не хватает.

Может изменить логику работы и не давать пользователям редактировать критичные для сайта таблицы? С чем связана такая необходимость?

Я таки _{очень надеюсь, что Евгения правильно} понял, что под редактированием имелся в виду процесс добавления, удаления и изменения строк таблицы, а не модификация её структуры.
Т.е. DML, а не DDL.

>Я таки _{очень надеюсь, что Евгения правильно} понял, что под редактированием имелся в виду процесс добавления, удаления и изменения строк таблицы, а не модификация её структуры.
Да
>Т.е. DML, а не DDL.
Этого у Симяднева в книге нет. Так что непонятно.
Надо почитать, чтобы ответить мне на свой вопрос?

To: GeorgeIV
Таблицы большие ~50M каждая и изначально содержат много ошибок (до 10%), кроме того страдают неполнотой (до 30%), но в некоторых случаях это почти незаметно, а в других случаях посетитель может подправить таблички, и всё заработает.
Только вот придётся, видимо, учитывать возможность, что кто-то будет вольно или невольно вносить ошибочную информацию.
Вот я и думаю, если это выяснится, как организовать процедуру отката ?

>>Т.е. DML, а не DDL.
>Этого у Симяднева в книге нет. Так что непонятно.
У Симдянова.

Чего нет?
И почему именно там?

Create table roll_up_back ( id INT(11),  date_time DATETIME, seq INT(11), operator_id INT(11), terminal_id INT(11), table_id INT(11), op TINYINT(1),  -- 1-del, 2-upd, 3-ins assign_list LONGTEXT )

Да. Я не люблю enum'ов.
Кому спичит, могут написать op ENUM ('-', 'del', 'upd', 'ins'),

Поле

assign_list LONGTEXT

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

roll_up_back

есть поле для названия изменённого поля, для старого значения, и для нового значения.
Всё бы хорошо, но поля могут иметь разные типы.
Фактически, в моих таблицах, относящихся к данному проекту, это ENUM, VARCHAR, INT, SET.
Возможно их свести к общему знаменателю? (Чтобы потом универсальный триггер отслеживающий обновления вешать на любую таблицу, не задумываясь о её структуре?)