我有一个跟踪会员卡持卡人的 Rails 应用，需要报告持卡人的状态。状态根据业务规则定义为“信誉良好”、“拖欠”或“已取消”，具体取决于持卡人最近的发票是否已支付。
发票是提前 30 天发送的，因此刚开具发票的客户仍然信誉良好，超过付款到期日 20 天的客户拖欠，会员未能支付发票超过到期后 30 天将被取消。
我正在寻找有关将持卡人的当前状态存储为客户级别的字段是否更好的建议（并在不更新相应持卡人记录的情况下处理发票记录的潜在更新导致的潜在更新异常） ，或者每次请求状态时根据数据库中的数据简单地计算当前持卡人状态是否更有意义（这可能会给数据库带来大量负载并降低应用程序的速度）。
建议？还是我没有想到的其他想法？
一个重要的限制：虽然不太可能有人直接修改数据库，但这种可能性总是存在的，因此我需要尝试采取一些保护措施来防止各种数据库记录彼此不同步。
【问题讨论】：
标签： ruby-on-rails model-view-controller data-modeling
最近我有类似的决定，我决定将状态存储为数据库中的一个字段。这是因为我想减少 sql 查询，它看起来更简单。我选择这样做是因为我经常需要获取此状态并且计算它（至少在我的情况下）有点复杂。
可能的问题是它不同步，所以我在子模型中添加了一些after_save 和after_destroy，以保持同步。当然，如果有人以不同的方式修改数据库，就会产生一些问题。
您可以编写简单的 rake 任务来检查所有状态，并在需要时进行更正。您可以在 cron 中运行它，因此您不必担心它。
【讨论】：
最简单的方法是在每次请求状态时根据数据库中的数据计算当前持卡人状态。这样您就不会出现数据重复，因此不会出现重复不同步的潜在问题。
当且仅当您的测量结果表明此计算导致显着减慢时，您才可以考虑缓存该值。
【讨论】：
在您的数据库中存储计算数据通常是一种优化。我建议您计算每个请求的值，然后监控应用程序的性能。如果不存储此数据这一事实对您来说是个问题，那么是时候重构并将值存储在数据库中了。
由于您提到的原因，存储计算值，尤其是那些可能影响多个表的值通常不是一个好主意。
当/如果您确实重构并将值存储在数据库中，那么您可能需要一个批处理作业来定期检查值的数据完整性。
【讨论】：