Рекомендации по обработке полей статуса объекта в приложениях rails: хранить или рассчитывать?

Question

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

Счета отправляются за 30 дней, поэтому клиент, которому только что был выставлен счет, все еще находится в хорошем состоянии, тот, кто просрочил срок оплаты в 20 дней, имеет задолженность, а участник, который не оплатил свой счет более чем 30 дней после этого будут отменены.

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

Рекомендации? Или другие идеи, о которых я не задумывался?

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

Answer 1

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

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

Если / если вы выполните рефакторинг и сохраните значение в БД, то вам, вероятно, понадобится пакетное задание, которое регулярно проверяет значение на целостность данных.

Answer 2

Недавно у меня было подобное решение, и я решил сохранить статус как поле в базе данных. Это потому, что я хотел уменьшить sql запросы, и это выглядит проще. Я решил сделать это таким образом, потому что мне очень часто нужно будет получить этот статус, и его вычисление (по крайней мере, в моем случае) немного сложно.

Возможная проблема в том, что он не синхронизирован, поэтому я добавил несколько after_save и after_destroy в дочернюю модель, чтобы синхронизировать ее. И, конечно, если кто-то изменит базу данных другим способом, это создаст некоторые проблемы.

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

Answer 3

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

Если и только если ваши измерения показывают, что этот расчет вызывает значительное замедление, вы можете подумать о кэшировании значения.