CQRS 中非规范化的最佳实践是什么？
我正在尝试创建一个守护进程来对我的数据库进行非规范化。
我使用 ActiveMQ 作为队列管理器 我有2个数据库：关系数据库（写入+复制）和非规范化数据库（用于读取）
我的问题是非规范化我的真实数据库的最佳实践是什么我有一些想法：
- MySQL代理（带有lua）读取队列（是这可能）
- 在 MySQL Java 守护进程中触发
- 作为读取队列 Cron 选项卡的服务
- ？ （但我会有很长的延迟时间
I am trying to create a deamon to denormalize my Database.
I use ActiveMQ as queue manager
I have 2 data bases: Relational one (write + replication), and denormalized one (for reads)
My question is what's the best practice to denormalize my real DB I have some ideas:
- MySQL proxy (with lua) which reads the Queue (is this possible)
- Trigger in MySQL
- Java daemon as a service which reads the Queue
- Cron tab ? (but I will have a big time of latency
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不确定这是否是官方的“最佳”实践，但总的来说，我发现事件溯源和使用事件驱动读取模型的写入和更新是一种很好的实践。通过事件溯源，写入模型本身并不作为关系数据库中的实体和关系存在，而是作为事件的历史记录（我知道这听起来很令人困惑），
您可以通过查看有关事件溯源的更多信息Eventide 如何实现它（在 Ruby 中）https://eventide-project.org/。
我还在这里对使用域事件的 CQRS 进行了简短介绍： http://lucisferre.net/2010/11/04/a-brief-introduction-to-cqrs/
但是，这并不能真正回答您直接的问题，最终事件来源可能不适合你。由于您已将“写入”模型的状态存储在关系数据库中，因此触发器是一种可能的方法，但是您将使系统非常以数据为中心。如果您可以在代码中使用触发器来完成同样的事情，那么它会更干净且更可测试。
为此，我仍然会使用域事件模式，并使用事件总线将事件发布到负责更新读取模型的事件处理程序。
将这些事件和处理程序视为 SQL 触发器，但基于域设计及其行为。 Udi Dahan 有很多关于这种方法的好材料，其中使用域事件来更新读取模型，但没有使用事件源。 http://www.udidahan.com/?blog=true
I'm not sure if this is an official "best" practice, but in general I find Event Sourcing and using events to drive writes and updates to the read model to be a good practice. With event sourcing the write model doesn't live as entities and relationships in a relational database per-se but instead as a history of events (I know that sounds pretty confusing at first)
You can learn a lot more on event sourcing from looking at how Eventide implements it (in Ruby) https://eventide-project.org/.
I also have a short introduction to CQRS using domain events here: http://lucisferre.net/2010/11/04/a-brief-introduction-to-cqrs/
However, that doesn't really answer your immediate question, and in the end event sourcing may not be for you. Since you have stored the state of your "write" model in a relational database then triggers are one possible way to go though, but then you are making your system very data centric. It would be much cleaner and more testable if you could accomplish the same thing using triggers in the code.
To do this, I would still use the domain events pattern and and use an event bus to publish the events to event handlers which have the responsibility of updating the read model.
Think of these events and handlers like your SQL triggers but based inside your domain design and it's behaviors. Udi Dahan has a lot of good material around this approach, where domain events are used to updated the read model, but event sourcing is not used. http://www.udidahan.com/?blog=true