Каков наилучший способ реализовать «мягкий» процесс сохранения или модификации?

Question

Я работаю над основанным на MVC веб-приложением на LAMP, которое требует изменения некоторых записей только с разрешения «старшего» пользователя. (Обычный пользователь может отправлять изменения, но они применяются только после этого утверждения)

Есть только таблица, в которой это должно произойти, скажем, "события":

СОБЫТИЯ - Я бы - имя VARCHAR - start_date DATETIME - гость INTEGER

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

Сначала я выбрал следующие опции:

• Дублирование каждого столбца, кроме идентификатора, скажем name_temp для "name", для хранения модификации, ожидающей утверждения.
• Создание отдельной таблицы с дублированной структурой и сохранение там всех ожидающих одобрения изменений.

Вы реализовали это раньше? Как вы думаете, что является лучшим / ваш способ сделать это? А также: Есть ли какой-нибудь шаблон для такого рода проблем?

Спасибо !!!

PD: мне нужно сохранить «старую» запись, где она была, до тех пор, пока новая не будет утверждена ..

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

Запись всех предполагаемых изменений во вспомогательную таблицу и их обработка (применение их к основной таблице, если они удовлетворяют определенным условиям) позже «пакетами», действительно, является распространенным шаблоном, часто полезным, когда требуется, чтобы основная таблица изменялась только при определенные моменты, когда предлагаемые изменения могут наступить в любое время, а также в других условиях, например когда запись в основную таблицу очень затратна (блокировка конкуренции или что-то в этом роде), но запись N изменений не намного дороже, чем запись, или проверка предложенного изменения занимает очень много времени (вы можете классифицировать ваш вариант использования как крайний случай последняя категория, так как в вашем случае проверка требует, чтобы человек посмотрел на предлагаемое изменение - ОЧЕНЬ медленно по компьютерным стандартам; -).

Answer 4

Почему бы не добавить еще 1 столбец с именем IsApproved? тип bool или tinyint (1)? и только сейчас показывают утвержденные события?

Редактировать : О, это утверждение каждого атрибута. Тогда 2-й стол будет моим выбором с именем PendingEventChanges с такой же структурой или просто id + изменяемые свойства, и при утверждении «супер» пользователь обновит исходные данные и удалит этри из ожидающих.

Первый выбор - против нормализации базы данных, поэтому добавление дополнительных свойств в будущем может вызвать проблемы.