Хранить историю это не прихоть, а практическая необходимость. Но вопрос про концепцию скорее не ко мне, я просто сделал упрощение рутинного процесса, а не предлагаю новую концепцию хранения.
Когда хранишь как скрипт - легко ошибиться. Процедурка привязана к конкретной СУБД (скрипт в дальнейшем будет расширять поддержку.
В корпоративных проекта (особенно в банковских) часто требуют нормализованную структуру с отдельной history-таблицей. А из практики - в реальных приложениях намного удобнее работать со строками, чем каждый раз разбирать json. Да и задача плагина - не изобрести новый способ хранения истории, а ускорить рутинный процесс.
Я выбрал кастомную лицензию, чтобы сохранить проект в том виде, в котором я его задумывал. Если у вас есть идеи или предложения по улучшению, их всегда можно оставить в репо в виде issue/feature request, с радостью ознакомлюсь :)
Спасибо за вопросы! Сейчас плагин в самом "сыром" виде. Поэтому он генерит append-only историю, это дает полный аудит, но, конечно, вызывает рост таблицы (благодарен за напоминание про bloat). В будущем планирую подумать над оптимизациями (замораживание, секционирование, режим хранения)
Добавил спойлер с sql скриптом (Под скриншотом со скриптом)
В ряде корпоративных проектов (например, в банковских), принято хранить историю изменений каждой записи. Это нужно для аудита, отката ошибок и в целом для отслеживания состояния объекта во времени. Обычно такие history-таблицы создают вручную, что довольно рутинно: прописать колонки, проверять корректность и избегать опечаток. Собственно, плагин и был сделан, чтобы этот процесс автоматизировать: выбираешь таблицу, нужные колонки и события - а скрипт генерится автоматически.
Вы не можете распространять изменённые версии плагина без согласия автора, но это не запрещает вам создавать пул/мердж реквест.
Т.е. пул/мердж реквест рассматривается как "согласование".
*(плагин в дальнейшем будет расширять поддержку СУБД)
Хранить историю это не прихоть, а практическая необходимость. Но вопрос про концепцию скорее не ко мне, я просто сделал упрощение рутинного процесса, а не предлагаю новую концепцию хранения.
Когда хранишь как скрипт - легко ошибиться. Процедурка привязана к конкретной СУБД (скрипт в дальнейшем будет расширять поддержку.
В корпоративных проекта (особенно в банковских) часто требуют нормализованную структуру с отдельной history-таблицей.
А из практики - в реальных приложениях намного удобнее работать со строками, чем каждый раз разбирать json.
Да и задача плагина - не изобрести новый способ хранения истории, а ускорить рутинный процесс.
Спасибо за комментарий, согласен.
Я выбрал кастомную лицензию, чтобы сохранить проект в том виде, в котором я его задумывал. Если у вас есть идеи или предложения по улучшению, их всегда можно оставить в репо в виде issue/feature request, с радостью ознакомлюсь :)
Спасибо за вопросы! Сейчас плагин в самом "сыром" виде. Поэтому он генерит append-only историю, это дает полный аудит, но, конечно, вызывает рост таблицы (благодарен за напоминание про bloat).
В будущем планирую подумать над оптимизациями (замораживание, секционирование, режим хранения)
Добавил спойлер с sql скриптом (Под скриншотом со скриптом)
Да, like быстро копирует структуру, но моя цель - автоматизировать вес цикл (хист таблица + триггеры). А так вы получаете лишь копию но без триггеров
В ряде корпоративных проектов (например, в банковских), принято хранить историю изменений каждой записи. Это нужно для аудита, отката ошибок и в целом для отслеживания состояния объекта во времени.
Обычно такие history-таблицы создают вручную, что довольно рутинно: прописать колонки, проверять корректность и избегать опечаток.
Собственно, плагин и был сделан, чтобы этот процесс автоматизировать: выбираешь таблицу, нужные колонки и события - а скрипт генерится автоматически.
Кто-нибудь может трезво спрогнозировать чем это нам грозит?