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
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
