Лучший способ создать таблицу истории для операций CRUD

Question

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

1. Использование триггеров
2. Добавить дополнительное заявление вставки в код, когда вставка/обновление/удаление личных данных, связанных с ним используется

Они сказали, что спусковые бы быть лучше, так как нагрузка будет на базе, а не в программе , Но поскольку на моем веб-сайте есть несколько администраторов, мне также нужно будет отслеживать, кто изменил контент, что, по моему мнению, будет возможно только путем создания столбца modified_by в таблице истории и вручную вставить в него значения, вставив пользователя сеанса в этот столбец, используя второй вариант вместе с значениями time_modified, modified_from, modified_to.

Мне нужно выяснить, было ли это приемлемой причиной для использования второго варианта? Есть ли еще варианты? Будет ли второй вариант создавать какие-либо проблемы в будущем?

Answer 1

Существует жемчужина Rails https://github.com/airblade/paper_trail, которая полностью реализует вашу указанную функциональность. Я бы предположил, что он делает это исключительно на уровне кода приложения, а не на уровне базы данных (триггеров). Это может также указывать на то, что вариант 2 лучше. Мои мысли:

1. Если вы используете триггеры, вы будете иметь серьезную торговлю производительности от, как ваш сайт трафик растет и CRUD операции идут вверх. Тогда будет много триггеров.

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

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

4. Сохранение истории увеличивает размер стола и может стать узким местом для производительности базы данных. У вас есть возможность хранить историю в течение ограниченного промежутка времени, а затем архивировать ее, чтобы таблица базы данных была чистой и чистой. Кроме того, вы можете иметь отдельный сервер базы данных, отвечающий только за связанные с историей таблицы. Эти вещи будут сложными для триггеров.

Answer 2

Я могу предложить решение # 2. Поскольку мне нравится, когда вся бизнес-логика содержится в одном месте (в PHP-сервере). Этот код будет более удобным и многоразовым. И вы можете сохранить только измененные поля в некоторый формат JSON. Поэтому он держит место на жестком диске и будет работать быстро. Я думаю, что триггеры - очень плохие вещи, потому что вы не знаете, что произойдет в следующий раз в БД (вы всегда должны помнить все триггеры) :) Поэтому я не использую его.

Только одна проблема у вас будет - много записей в таблице истории. Поэтому я рекомендую удалять записи, старейшие, что 3 месяца

Answer 3

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

Например, если вы использовали Propel, он поставляется с versionable behaviour, который управляет отдельной версией таблицы и номерами версий для каждой строки.(Кроме того: я считаю, что версия 2 еще не была выпущена как стабильная, хотя она связана с домашней страницей проекта. Я использую версию 1.7, которая по-прежнему превосходна. Обе версии имеют эту функцию, насколько я знаю).

У доктрины есть аналогичная функция, Versionable, хотя, похоже, это устарело в пользу EntityAudit.