How to properly implement a database structure where a user has multiple balances?

Question

Database design

I see 2 options
1.

balances
id userId balanceOne balanceTwo ...

2.

balances
id name

user_balances
id userId balanceId value
1      1           1            0
2      1           2            100
3      1           3            99

It's easier for me to work with the 1st option, because there are no additional requests, but from the point of view of the client side, I don't know how it will be easier for them to make requests for data / interaction. They will send id-ik or just a string by which I will pull out the value. I have not started work yet and am thinking about all the problems / difficulties that may arise. Perhaps someone has done similar things and can suggest a solution.

Answer 1

The second option is clear. Forget the first one like a bad dream.

Answer 2

Both options can be selected.
The second option is ideologically correct, in some sense it is simpler (although who knows), it is expected by most developers who will pick your code and is also applicable to any ORM libraries.
But if ideologically, different balances are different types of objects, and not just a lot of the same (a rough example of balances in different payment systems, or balances in different currencies, against several wallets with the same currency), especially if the type reference will rarely change (by the way, this is not such a problem), then the first approach is justified.
The first approach is much more complicated, since it implies mechanisms for generating sql queries based on actions from the user interface, while the second one allows you to fix the query structure (this simplifies debugging, minimizes the number of errors). By the way, the first approach will give less load on the database, but it seems insignificant to me, because instead of working with two tables and a set of indexes, one will be used, since when working, even before the query, it is known in which column the required balance will be.