跟踪用户愿望清单上产品价格下降的方法？答案

【问题标题】：Method to track price drops for a product on a user's wishlist?跟踪用户愿望清单上产品价格下降的方法？
【发布时间】：2010-12-26 22:54:46
【问题描述】：

假设我有这些表/模型：

Product
- id
- last_updated_date
- name
- price

User
- id
- name

WishlistItem
- id
- user_id
- product_id

Product 表有几百万条记录，每晚通过数据导入自动更新（插入新表，删除旧表）。我基本上对该表/模型具有只读访问权限。

如果产品在用户的心愿单上并且价格下降，我希望能够通知该用户。有哪些方法可以做到这一点？

我有几个想法：

跟踪愿望清单模型中的 Product.last_updated_date 并定期轮询产品表以查看它是否已更新。这听起来像是一个可怕的/不可扩展的解决方案。
在产品表更新时触发的某种 Postgres 视图或函数？我是 postgres 的新手，所以我还不确定这是否可能。
你会建议我没想到的令人惊奇的事情:)

非常感谢任何正确方向的帮助！

更新：提出的一个想法是将当前价格缓存在愿望清单条目本身中，即：

WishlistItem
- id
- user_id
- product_id
- price

...然后，在导入之后，我可以将 WishlistItem.price 与 Product.price 进行比较并相应地通知。虽然可行，但这种方法似乎有点浪费，因为每个用户的每个 WishlistItem 基本上都将具有相同的价格数据缓存副本，如果有更新，我将不得不用新价格更新每个列表。不过，我不确定是否有解决方法。

更新：最后我决定我应该只跟踪所有版本的数据，以便我可以在更新触发器上使用标准。这也让我可以记录所有价格变化，以便跟踪定价趋势等。

【问题讨论】：

您的更新符合我下面的建议，非规范化价格。由于您替换了产品表，因此您需要在其他表中记录原始价格。正如您所说，需要通过更新愿望清单表来标记通知，还有其他解决方案，例如，拥有一个通知表并且每个用户/产品只允许一个通知（只需添加愿望清单的 id 并使其唯一） .

标签： ruby-on-rails postgresql triggers notifications ruby-on-rails-3

【解决方案1】：

您可以在Product 上使用更新触发器，但听起来Product 表实际上并没有被更新，它正在被替换；如果是这种情况，则没有更新来触发触发器，因此您必须通过在 Wishlist 中缓存价格（如 user247245 注释）并扫描 Product 以了解价格变化来艰难地做到这一点。

如果Products 正在更新而不是批发替换，则可以使用更新触发器来记录价格何时发生变化并安排通知相关方。触发器可能会通过将通知插入到名为Product_price_changes 的单独表中（以避免锁定Products 更新）来排队通知；然后，当Products 更新完成后，一个单独的任务可以将Product_price_changes 与Wishlist 进行比较，通知感兴趣的用户，最后删除Product_price_changes 中的所有内容。

请注意，最新版本的 PostgreSQL 您可以将更新触发器限制为仅在列更改时触发，而不是在每次行更改时触发。

【讨论】：

如果表没有被批量替换，更新触发器似乎是正确的方法，但确实如此。不幸的是，Products 表很大，导入数据需要很长时间。替换表（而不是 UPSERT-ing 行）显着加快了它的速度，但我失去了使用更新触发器的能力。我想我必须评估哪个更重要：总导入速度或拥有更新触发器的能力。我想我可以在导入完成后使用创建product_price_changes 的 ruby 观察者来模仿相同的功能。
Product 中的值多久真正改变一次？如果每日产品数据转储来自外部来源，您可能能够制定差异/补丁交易（甚至可能是文本文件上的简单 diff(1)）系统，以将其缩减为一小部分更改，然后将这些更改应用到Product 表。诀窍是减少工作量或将其分散成小块，以避免锁定Product 并妨碍在线系统。希望“大数据库”团队明天会出现一些新想法。
好吧，它们可能不会经常更改，但问题是我正在处理的记录和数据量很大......总共有几百万条记录，所以即使它们中的一小部分更新了，数据还是蛮多的。（我也在导入其他表，这只是一个有点大的数据集中的一部分。）不过你是对的，我可能需要重新考虑在导入时完全替换这些表......
对，如果你的干草堆是一座城市那么大，你有多少针都没关系。重新考虑“替换表格而不是更新表格”策略可能是要走的路；替换它还可以轻松添加外键以确保引用完整性：损坏的代码可以修复，损坏的数据可能无法修复。
最后，正确的答案似乎是在每次导入后跟踪数据的不同版本。这也将有助于能够看到一段时间内的定价趋势。你是对的，损坏的代码可以修复，但损坏的数据是完全不同的问题。谢谢。

【解决方案2】：

我会在愿望清单表中添加一个字段“价格”。更新产品表查询以降低价格并生成通知表作为结果

问候， /t

【讨论】：