В настоящее время мы пытаемся спроектировать простой модуль для нашей системы, чтобы сделать его проверяемым, но мы не уверены в том, какая стратегия лучше.Мы хотим попытаться сделать это как можно раньше, потому что после запуска приложения перенос всех данных в другую стратегию может стать ошибкой.
Стратегия 1 - наш текущий выбор
Система, с которой мы сейчас экспериментируем, состоит в создании новой записи каждый раз, когда производится обновление, и при запросе просто получайте записи с самой последней отметкой времени created_on.В случае, если у нас есть отношения родитель-потомок, и дочерний объект должен быть обновлен, мы просто обновили бы дочерний элемент, а не родительский.Запрашивая их, мы применяем одну и ту же стратегию для каждого зависимого отношения.
Стратегия 2 - нам это не очень нравится
Еще одна стратегия, о которой мы думали, - это иметь два столбца в каждой таблице., отметки времени valid_from и valid_to.Каждый раз, когда мы обновляем запись, мы заполняем valid_to предыдущей действительной записью и оставляем текущую пустое значение.Мы будем следовать той же стратегии извлечения, что и в предыдущем случае.
В заключение хочу подчеркнуть, что основная причина, по которой мы не придерживаемся стратегии 1 , заключается в том, чтобысохранить данные, это требует от нас пройти довольно сложный процесс сравнения, который нам не нравится .Каждый раз, когда веб-интерфейс вызывает наш API с новой полезной нагрузкой, мы выбираем последний агрегат (родитель + дети + внуки и т. Д.), Выполняем полный анализ и определяем, что обновлять.
Поэтому мой вопрос к вам, ребята, таков:Вы использовали какие-либо другие стратегии аудита, которыми вы гордитесь и хотели бы поделиться?