I have that that kind of divisive discussion. But we did compromise. What we ended up doing was using an ORM for CRUD operations, which were mostly user-facing ('row' operations); and SQL for reports / data monitoring ('column', bulky operations). And doing our most to avoid procstocs (limit them to executing REFRESH MATERIALIZED VIEW and COPY operations to the best of our ability), and trigger processing.
We do manage the SQL code (view definitions, mviews, and the remaining procstocs) right next to the application code with Flyway [1]. We also have SQL-ORM integration tests, spinning a database container with testcontainers [2].
We've had some issues with business rule duplication (updating the ORM and forgetting to do the same in SQL), but so far I'd say it's successful.
This being said, I'm on the SQL boat; and I remain convinced that the CRUD could be done comfortably with an SQL query builder such as jOOQ [3]; and that it would help solving the business rule duplication issue. But hey it's working right now and everybody is happy about it, so why change it?
We do manage the SQL code (view definitions, mviews, and the remaining procstocs) right next to the application code with Flyway [1]. We also have SQL-ORM integration tests, spinning a database container with testcontainers [2].
We've had some issues with business rule duplication (updating the ORM and forgetting to do the same in SQL), but so far I'd say it's successful.
This being said, I'm on the SQL boat; and I remain convinced that the CRUD could be done comfortably with an SQL query builder such as jOOQ [3]; and that it would help solving the business rule duplication issue. But hey it's working right now and everybody is happy about it, so why change it?
[1] https://flywaydb.org/
[2] https://www.testcontainers.org/
[3] https://www.jooq.org/