16 ms·
>Of running a SQL query on the same database you're already using Go back and read OPs link. They create new SQL types, tables, triggers, and functions, with n
by daenz 5y ago
>Of running a SQL query on the same database you're already using
Go back and read OPs link. They create new SQL types, tables, triggers, and functions, with non-trivial and very unforgiving atomic logic. And every system that needs to read or write from this "db queue" needs to leverage specific queries. That's the complexity.
>vs writing code to support some other new system
You mean using a stable well maintained library with a clean and sensible interface to a queueing system? Yes, that is far more simple.
- option_greek 5y agoNot necessarily. Many languages like Java already have queuing libraries that operate on rdbms through JPA. So not even a single additional line needs to be written for this to work. We got ours working in a day and it works great. I don't know if other languages have these libraries but I'm inclined to believe they do (at least nodejs has).
- daenz 5y agoDo you have to set up the triggers, tables, and procedures beforehand or how does that work?
- option_greek 5y agoThe libraries create their own tables, triggers etc during initialization.
- daenz 5y agoSo your application needs privileged access (to create tables, triggers, etc) to the database in order to run? That's an anti-pattern. Your deployed application should only need least privileges possible. If you need to do extra things to your database, it should be done in migrations, which should be more privileged, but now you've decoupled the creation of these extra db objects from the library itself, meaning if the library changes, your migrations will not be in sync.
- mlyle 5y agoNo... JPA writes out a file with the necessary DDL and the administrator runs it. If this is insufficient for more complicated migrations, there's tooling to support it. e.g. Flyway.