Re: using a postgres table as a multi-writer multi-updater queue

On 11/23/2015 2:51 PM, Merlin Moncure wrote:
> On Mon, Nov 23, 2015 at 12:54 PM, John R Pierce<pierce(at)hogranch(dot)com> wrote:
> >
> >depending on where these queue entries are coming from, I'd considering
> >using a message queueing system like AMS, MQseries, etc, rather than trying
> >to use a relational database table as a queue. your external data source(s)
> >would write messages to this queue, and you'd have 'subscriber' processes
> >that listen to the queue and process the messages, inserting persistent data
> >into the database as needed.
> I just don't agree with this generalization. Keeping the state of the
> queue in the database has a lot of advantages and is a lot easier to
> deal with from a programming perspective especially if SQL is your
> core competency. Being able to produce and consume in SQL based on
> other relational datasources is...elegant.

our whole system at $job is message based as its a distributed
system. clients send messages to middleware servers that talk to the
database servers. noone talks directly to the database, instead they
use messaging. also the several databases in our core cluster talk to
each other with messaging, where the front end database publishes events
that the other reporting database servers subscribe to. its a very
powerful model for building complex distributed systems and maintaining
quite a lot of implementation flexibility, as the exact nature of the
schema only needs to be known by a few publisher and subscriber modules.

--
john r pierce, recycling bits in santa cruz