How to properly design the relationship between API and DB?

Question

PostgreSQL

I noticed a few problems in the application and would like to understand how to solve them:
1. The backend accesses the database and gets some fields, then works with them as is. That is, if a field has arrived and is called let's say sum, then it will be used everywhere in the application as sum. It seems to me that there is a dependence on the database, and any changes require a change in the database.
2. It follows from the previous that the fields that come when requesting the API are named the same as elsewhere on the backend, which depend on the name in the database. That is, it turns out the end-to-end dependence of the API on the database.
3. Some API requests are almost like going to the database, because behind this request there is an SQL query to the database and we get what came from there.
Actually how much is all this right? Perhaps this is generally the norm. And what hikes, tools, etc. can and should be explored to solve these problems?

Answer 1

I suggest you study Martin Fowler's Enterprise Application Design Patterns. The book analyzes approaches for various options for building an architecture. Better in english.

Answer 2

and any changes require changes to the database.

no
DBMS storage - valid data in 3 normal form (3NF). Point
Between the database and the api there is always a gasket in the form of a backend - do whatever you want there (which is easier to do in the PL, and not in the sequel)
3. OK. Go ahead and don't be embarrassed. Use an ORM

Answer 3

There are two approaches Code first and Database first, different tools may implement one or both. In the first, the database structure is determined by the code, and in the second, vice versa.
The field/column name can be changed, but if there is something else in place of sum, what will it change for you?
In general, it all depends on the task. Data can be stored in the database, and then transformations are performed at the service level, which give the data a new quality. Therefore, learn to think not in code, but in the problem that you are solving.