That sounds like SOAP + SQL Server stored procedures (full replication mode to log db requests, then monitor any SQL queries). I'm assuming other vendors have similar set ups.
I've ran systems like that, and I'm glad things are a lot easier to maintain now (stored procs are a pain in the ass, whether they exist in the database or in the app layer).
Query injection is solved by parameterising queries (never sanitising them yourself), it should not be an issue nowadays, "advanced SQL injection" is a lie, either you can inject or you can't.
If you can inject, it doesn't matter how many protections you put in place, you can always extract data via timing attacks or boolean conditions.
Your SQL is going to be "stored" one way or another, whether it's implicitly in the internal workings of an ORM, explicitly in code or mybatis style config, or explicitly in the DB. I think isolating it into data workers, and making them feed off a high throughput message queue (hiding restarts), minimizes the amount of redeploying needed.
I've ran systems like that, and I'm glad things are a lot easier to maintain now (stored procs are a pain in the ass, whether they exist in the database or in the app layer).
Query injection is solved by parameterising queries (never sanitising them yourself), it should not be an issue nowadays, "advanced SQL injection" is a lie, either you can inject or you can't.
If you can inject, it doesn't matter how many protections you put in place, you can always extract data via timing attacks or boolean conditions.