Am Mittwoch, 2. Mai 2018, 19:36:11 CEST schrieb Alex Balashov:
By way of further answer:
The use of a database as an interprocess communication mechanism is considered an antipattern (the opposite of a "best practice"):
https://en.wikipedia.org/wiki/Anti-pattern#Software_design https://en.wikipedia.org/wiki/Database-as-IPC
While relational databases perform the worst at this, the fundamental problem is using the database as a work queue for ephemeral/real-time data. Simply using a faster, and/or nonrelational database, doesn't remove the problem, it just makes the setup perform better. It's a difference of degree, not kind.
Ultimately, databases — including in-memory key-value stores — are for storage, not for IPC. This doesn't stop them being routinely used as such by people who do not know how to write IPC mechanisms and middleware of their own. That's less excusable in an era with lots of prefabricated options, whether message queues (e.g. AMQP) or distributed systems closer to the application level (like DMQ).
Hello Alex,
you are right of course regarding the comments about the anti-pattern using databases as IPC.
But IMHO there are valid use cases for storing a registration in a database, like access for third party applications. E.g. you have a front end that shows customer care if a user is registered or not, and you don't want that this PHP GUI access directly your Kamailio servers. Or you need to access the registration data in a big java enterprise middle-ware for user contract status.
But in a smaller or more homogeneous environment its of course easier to synchronize the registration state with DMQ.
Best regards,
Henning