根据数据库行中的更改向用户发送警报
有10,000个用户。每个都可以为企业供应链库存定义多达500个条件。
条件的一个示例可能是
Group1
Item in InventoryX > 5000 AND colourItem == Red
AND Group2
Item in InventoryY > 4000 and colourItem == Green
每当数据库状态（库存中的单行，库存和颜色列中的单行）与上述条件相遇时，应通知创建警报的用户。
想到的第一个解决方案是在给定的时间间隔（例如1分钟）继续对数据库进行不断进行轮询，但是每个分钟的问题都会是10000 x 500的民意调查。
这很难扩展。
我们还需要记住，给用户提供了一个简单的前端来创建条件，并且他们可以根据其一时兴起来更新这些条件。没有硬编码可以起作用。
什么可以用来实现相同的更好的体系结构/项目？
数据库= PostgreSQL。 https://www.postgresql.org.org.org.org/docs/current/current/current/sql-notify。 html 似乎很难实施，因为对于如此多的条件不容易使用。
There are 10, 000 users. Each can define up to 500 conditions for an enterprise supply chain inventory.
An example of a condition could be
Group1
Item in InventoryX > 5000 AND colourItem == Red
AND Group2
Item in InventoryY > 4000 and colourItem == Green
Whenever the state of the database (single row in InventoryX, InventoryY, and colourItem columns) meets to the condition mentioned above, the user who has created the alert should be notified.
The first solution that comes to mind is to continuously keep polling the database, at a given time interval (say 1 minute) but the problem with it would be every minute there will be 10000 X 500 polls.
This is difficult to scale.
We also need to keep in mind that the user's are given a simple front-end to create conditions, and they can update these conditions as per their whim. No hard coding can work.
What would be a better architecture/project to be used to achieve the same?
Database = PostgreSQL.
https://www.postgresql.org/docs/current/sql-notify.html
Appears difficult to implement since there is no ease of usage for so many conditions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您只有三个选项：
您是否喜欢＃2还是＃3取决于有多少规则，需要多长时间检查每个更改的行以及是否可以用途总结更改还是合并警报。
＃2和＃3都将使用一个或多个触发器。选项＃2将运行规则并将条目添加到“警报”排队表（或
notify侦听过程以发送警报或在memcached/redis等中设置标志）。选项＃3只需注意更改行的ID，或者也许是更改的详细信息，您将有另一个过程读取更改并生成警报。这使您有机会注意到进行了两次相同的更改，并且仅发送1个警报或类似的情况，如果对您有用。
You only have three options:
Whether you prefer #2 or #3 depends on how many rules there are, how long it takes to check them for each changed row and whether you can usefully summarise changes or merge alerts.
Both #2 and #3 would use one or more triggers. Option #2 would run the rules and add entries to an "alerts" queueing table (or
NOTIFYa listening process to send an alert, or set a flag in memcached/redis etc).Option #3 would just note either the IDs of changed rows, or perhaps the details of the change and you would have another process read the changes and generate alerts. This gives you the opportunity to notice that the same change was made twice and only send 1 alert or similar if that is useful to you.