Ease of solution vs smearing business logic in the database?

Question

Software design

There is a solution to the problem that can be implemented in two versions
1) SQL query containing aggregation, case, group by
2) Manually describe the logic of aggregation, case and group by in the business logic layer on your main PL

The first option is much simpler, and contains less code. On the other hand, business logic is obviously smeared across the database layer.

How to decide which option to choose - a simple one with database blurring or a complex one with a clean architecture?

Answer 1

Immediately reservation - my answer refers to aggregations. I see no reason to give the case to the SQL side. If there is a reason, we can discuss separately.
Regarding aggregations.
Here the decision is not made in this context at all.
First you need to decide how much the application will scale and how.
If no special scaling is expected , then it is worth starting from the fact that the main task of SQL is to work optimally with data using indexes and other tricks. If the logic is transferred to the "client", then working with data will not be as effective.
Therefore, it is better to focus on the fact that from SQL to the "client" to drive as little data as possible, and the rest of the processing is already on the "client".
If it is supposed to scale the "client" instances while maintaining a single SQL database , then it is rather the other way around, you need to transfer more logic to clients. Here it makes sense not to do aggregation on the server. But it’s also better not to do it on the “client” every time, it’s best to somehow calculate them in advance and pull them out with a simple select.
The case when you need to scale hard (both the client and the SQL server) will not be considered here. Something tells me that those who need it will not read this article;)