On 10/01/25, 'Brian Candler' via golang-nuts (golang-nuts@googlegroups.com) wrote: > On Thursday, 9 January 2025 at 19:49:23 UTC Roland Müller wrote: > > > Reason for that is that doing all DB access methods in the application > > language (Go or Java) tends to a codebase where you have SQL code snippets > > scattered over in your code. When the application now grows it will be more > > and more demanding to make changes. Thus, this does not scale up. > > The solution to that problem with sqlc is to *centralize* all your SQL code > snippets in one place. This then becomes a set of known, supported > interfaces that the application is permitted to use (as an auto-generated, > clean Go API). The application cannot use ad-hoc SQL.
If the project doesn't need to move database type (in my experience middleware changes more often than the database on longterm projects), it is worth considering using procedural sql, for instance PL/PGSQL for Postgres. PL/PGSQL can provide a database "shell" to the database with several conveniences including per-request auth, simple solutions to the so-called n+1 problem and convenient testing within a transactional environment. Since a major capability of databases is generating composite results that don't naturally fit with the entities from which they are derived (in database tables or middleware types), working with procedural SQL can also help make the most out of the relational power of SQL. I haven't looked at sqlc's support for procedural sql, but in the past I've used a simple go tool to generate code from PL/PGSQL functions -- see https://github.com/rorycl/pgtools/tree/main/go-modelmaker. Cheers, Rory -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/Z4Eftpt9r-WhDrIF%40campbell-lange.net.
