MSMQ Versus a DB Table
Why should i use MSMQ when i can create a simple table in my db that does essentially the same thing, and is easier to query? I won't have to run all the MSMQ services, and have a box sitting there managing the queue.
Hey, you don't need to convince us. If the shoe fits, wear it . . .
MSMQ is likely overkill if all you want is a queue-type thing on a single machine. As you have deduced, a table might be the simplest approach. The benefit of MSMQ is when you want to *communicate with another machine* and you want it all to carry on working (eventually) if it goes offline temporarily.
Another benefit of MSMQ is having fun while troubleshooting it using clues like 'ASSERT failed on line 57' in the event log.
One possible reason for using MSMQ instead of a database:
MSMQ is very useful when you have many writers who all want to insert into a single table. Even MSSQL would have performance problems with 500 applications trying to write to the same table. So, what you do instead is have the apps write to a Queue, and have a service pulling the messages off the Queue and writing them to the table. The database is happy (only one writer to that table), and you get a measure of resiliency to your system (if the writer service goes down, you can start another instance of the service on another box via MOM or NetIQ script, or just write a cluster-aware service).
Fog Creek Home