Как правильно реализовать структуру БД, где пользователь имеет несколько балансов?

Question

[gomerIT]

я вижу 2 варианта
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

Мне проще работать с 1-ым вариантом, потому что нет доп.запросов, но с точки зрения клиентской части я не знаю, как будет проще для них составлять запросы на получение данных/взаимодействия. Будут отправлять они id-ик или просто строку по которому я вытащу значение. Я не начал еще работу и обдумываю все проблемы/сложности, которые могут появиться. Возможно кто-то делал подобные вещи и может подсказать решение.

Comments

[gomerIT]

Лентюй, Я все понимаю. У вас был трудный день и нужно на ком то оторваться. Надеюсь вам от этого стало легче.

Answer 1

[oleg_ods]

Второй вариант однозначно. Про первый забудь как про страшный сон.

Comments

[oleg_ods]

Лентюй, Могу)

Необходимость менять структуру таблицы в случае добавления еще одного баланса.

Более подробно все последствия ищутся по запросу «нормальные формы БД»

[alexalexes]

Лентюй, первая структура годится, если уверены, что одна сущность баланса будет обладать исключительно одной характеристикой - уровень баланса. Если нужно работать не только с уровнем баланса конкретного пользователя, а еще иметь доступ к характеристикам класса сущности баланса - знать его имя, краткое название, аббревиатуру, то такие сведения хранят в таблице справочнике.
Конечно, можно, используя первую схему, по порядковому номеру колонки соотносить класс сущности баланса с таблицей-справочником, однако составление таких запросов будет обусловлено с доступом к служебным таблицам СУБД, что в классических запросах будет выглядеть довольно дико и костыльно. Как вы это себе представляете?

Answer 2

[rPman]

Оба варианты могут быть выбраны.
Второй вариант идеологически верный, он в каком то смысле проще (хотя как знать), ожидается большинством разработчиков, которые будут ковырять ваш код а так же применимы к любым ОРМ библиотекам.

Но если идеологически, разные балансы - это разные типы объектов, а не просто много одинаковых (грубый пример балансы в разных платежных системах, или балансы в разных валютах, против несколько кошельков с одной и той же валютой), особенно если справочник типов будет меняться редко (кстати не такая уж это и проблема), то первый подход - оправдан.

Первый подход сильно сложнее, так как подразумевает механизмы генерации sql запросов на основе действий из пользовательского интерфейса, когда как второй позволяет фиксировать структуру запросов (это упрощает отладку, минимизирует количество ошибок). Кстати первый подход даст меньше нагрузку на базу данных, но мне кажется незначительную, ведь вместо работы с двумя таблицами и набором индексов, будет использоваться одна, так как при работе еще до запроса известно, в какой колонке будет искомый баланс.