5

I will be developing a system that will involve a data acquisition server where each acquisition will fill a row. I also need to have the ability to inform the user application of when new data has been acquired.

From what I have read, it's not a good idea to use a database as a message queue and vice versa, but I was wondering if I could use both?

The acquisition application can add the new row into the database and then notify the listeners in the messaging system. Would this be the best approach for this type of system? Would it be too complex? Is there a design pattern that already implements this?

CookieOfFortune
  • 13,836
  • 8
  • 42
  • 58
  • @CookieOfFortune- I'm struggling with this same issue. Do you have an y articles that point out why to use message queues instead of databases? – Hairgami_Master Jul 17 '12 at 22:33
  • Man, this question was a long time ago. I think the point I got out of this is that "events" and "persistence" should be separate. You could implement events using a database if you'd like, but you should keep is conceptually independent of storage. Using only messages has advantages because your processes can operate without state. This can make your code simpler (especially if you want to parallelize it). In terms of using message queues, they are specialized for events. That means they'll probably have better performance and allow for more complex messaging schemes. – CookieOfFortune Jul 18 '12 at 16:48

1 Answers1

2

Yes, inserting a row in the database and updating the GUI are two distinct operations, which should be separated.

What you are suggesting sounds good:

  1. insert a row in the DB
  2. notify the user application via a notification mechanism (listeners will do fine).
Eric Eijkelenboom
  • 6,943
  • 2
  • 25
  • 29