我应该使用消息传递而不是数据库吗
我正在设计一种系统，允许用户从一个系统获取数据并发送给其他系统。其中一个目标系统具有复杂的 SOA（Web 服务），另一个是接受平面文件输入的大型机。
我创建了一个包含 PublishEvent 表和 PublishEventType 表的数据库。还有特定于所发布的事件类型的规范化表。
我还有一个“接口”表，它是标准化数据表的扁平化版本。最终用户有一个将数据放入接口表的过程。我不确定确切的过程 - 我认为这是某种报告应用程序，他们可以将结果导出到 SQL 表。然后，我使用 SSIS 包从接口表中取出数据并将其放入规范化数据结构中，并在 PublishEvent 表中创建新行。我使用平面表是因为当我第一次向他们展示关系表时，他们似乎很困惑。
我有一个 Windows 服务，用于监视 PublishEvent 表中的新行。 Windows服务通过插件进行了扩展（使用MEF框架）。调用哪个插件取决于 PublishEvent 行中 PublishEventTypeID 字段的值。
PublishEventTypeID 1 调用从一组表读取数据并调用 SOA Web 服务的插件。 PublishEventTypeID 2 调用从一组不同的表读取数据并创建要发送到大型机的平面文件的插件。
这看起来像是我正在实现“Database as IPC”反模式。我应该改变我的设计以使用基于消息传递的系统吗？将数据放入平面表然后放入标准化表的过程是否多余？
编辑：这是在 .NET 3.5 中开发的
I am designing a system that will allow users to take data from one system and send to other systems. One of the destination systems has a sophisticated SOA (web services) and the other is a mainframe that accepts flat files for input.
I have created a database that has a PublishEvent table and PublishEventType table. There are also normalized tables that are specific to the type of event being published.
I also have an "interface" table that is a flatened out version of the normalized data tables. The end user has a process that puts data into the interface table. I am not sure of the exact process - I think it's some kind of reporting application that they can export results to a SQL table. I then use an SSIS package to take the data out of the interface table and put it into the normalized data structure and create new rows in the PublishEvent table. I use the flat table because when I first showed them the relational tables they seemed to be very confused.
I have a windows service that watches for new rows in the PublishEvent table. The windows service is extended with plug-ins (using the MEF framework). Which plug-in is called depends on the value of the PublishEventTypeID field in the PublishEvent row.
PublishEventTypeID 1 calls the plug-in that reads data from one set of tables and calls the SOA Web service. PublishEventTypeID 2 calls the plug-in that reads data from a different set of tables and created the flat file to be sent to the mainframe.
This seems like I am implementing the "Database as IPC" anti-pattern. Should I change my design to use a messaging based system? Is the process of puting data into the flat table then into the normalized tables redundant?
EDIT: This is being developed in .NET 3.5
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
MOM 可能是更好的解决方案，但您还必须考虑以下几点：
客户的架构？如果没有，也许介绍它是一个
矫枉过正。
平板支撑正确提到，你必须考虑具体的
这些模式，例如必须确保按时间顺序排列
消息、管理死信频道等（请参阅此
预订了解更多）。
与接口的选项。谁来照顾这一层
将把“消息”（基于 DB 或 MOM）转换成某种东西
那主机能消化吗？假设是你，会不会是
通过访问数据库（也许你有
过去已经解决过这个问题）或者会努力吗
根据使用 DB 或 MOM 的不同而有所不同？
总结一下：如果您对走数据库路线更有信心，也许最好这样做，即使 - 正如您正确地建议自己的那样，这有点“反模式”。
A MOM is probably the better solution but you also have to take in account the following points:
customer's architecture? If not, maybe introducing it is an
overkill.
Plank correctly mentioned, you have to take in account specific
patterns for these, like having to ensure chronological order of
messages, managing dead letter channels and so on (see this
book for more).
options for interfacing with. Who will take care of the layer that
will transform "messages" (either DB or MOM based) into something
that the mainframe can digest? Assuming it is you, would it be
easier (for you) to do that by accessing the DB (maybe you have
already worked on the problem in the past) or would the effort be
different depending on using a DB or a MOM?
To sum it up: if you are more confident by going the DB route, maybe it's better to do that, even if - as you correctly suggested yourself, it is a bit of an "anti-pattern".
需要记住的一些关键事项是：
行顺序一致性 - 您的数据模型是否取决于生成的数据的顺序？如果是这样，您的方案是否确保发布和订阅活动的创建顺序与原始数据的创建顺序相同？
两边都有身份栏吗？它们是一个问题，因为它们的值根据数据插入的顺序不断变化。如果标识列是唯一的主键（代理键），则更改其值可能会导致数据无法使用。
如何证明自己没有丢失记录？这是解决方案中最棘手的部分，尤其是当您有数百万行时。
至于架构，您可能需要查看 XMPP 协议 - 用于客户端（如果是 Java）的 Smack 和用于服务器的 eJabberD。
Some key items to keep in mind are:
Row order consistency - Does your data model depend on the order of the data generated? If so, does your scheme ensure the pub and sub activity in the same order original data is created?
Do you have identity columns on either side? They are a problem since their value keeps changing based on the order the data is inserted. If Identity column is the sole primary key (surrogate key), a change in its value may make the data unusable.
How do you prove that you have not lost a record? This is the trickiest part of the solution, especially if you have millions of rows.
As for the architecture, you may want to check out the XMPP protocol - Smack for client (if Java) and eJabberD for Server.
如果您使用 .Net，请查看 nServiceBus、Mass Transit 或 RhinoServiceBus。
Have a look at nServiceBus, Mass Transit or RhinoServiceBus if you're using .Net.