Earlier quoted context omitted.
> How? Stored procedures? Not neccesarily. jOOQ[1] and sqlc[2] are great options if you don't like stored procedures, but for a small app or a prototype, just having plain SQL strings in your app is fine. My point isn't that the code has to be stored in the database, but rather that the processing happens in one place where your data is stored and your middle tier just gets the results. Pure, stateless data. This mea…
I don’t get this at all, and I tried to understand it. I'm good at SQL. When necessary (maybe once a year), I can drop into pure SQL instead of Django ORM like it's nothing. The thing is, I can't imagine why I would ever want to. All these anti ORM comments read like they want to be as close to the DB as possible. This is not what I want. I don't care about guaranteeing the most efficient query, because it is never t…
SQL is the most high level language in common use. It abstracts away everything: Storage, memory, concurrency, and, most importantly, control flow. Complexity comes from complecting things, simplicity comes from decomplecting [1] things. SQL decomplects the what (data flow) from the how (control flow) which means less cognitive load, higher developer productivity and better maintainability.
In my experience, writing business logic in SQL results in fewer bugs and less code. I have replaced 50-line Java methods with 15-line SQL projections multiple times. With Python, the ratio is closer to 2:1, but it's still impressive.
And all of this without having to consider type impedance, eager versus lazy loading, result set mappings, second-level caching, dirty tracking, lifecycle management, OCC, or obscure savepoint bugs. Performance is just a nice, but welcome side effect.