Разделение и объединение объектов из таблиц базы данных в статических языках.
Учтите, что в базе данных у вас есть таблица users и стол называется wallets, Среди прочего у пользователя есть 0, 1 или более кошельков. Отношение «один ко многим» означает, что у кошелька есть внешний ключ, указывающий на пользователя.
Теперь вопрос в следующем: при построении структуры или класса для человека я вижу две возможности:
1) У пользователя нет знака кошелька. Существует функция, которая принимает пользователя в качестве аргументов и извлекает массив кошельков.
2) Пользователь имеет в качестве члена массив, содержащий кошельки, и кошельки выбираются при создании объекта / структуры.
Я думаю, что первый подход может быть лучше, поскольку он более модульный — во втором пользователи зависят от кошельков, даже если у пользователя нет кошельков.
Тем не менее, я не уверен, какой подход лучше, поэтому я ищу сравнение обоих подходов.
Решение
На уровне приложения у вас может быть такой тип пользователя (запись Go):
type User interface {
Wallets() []Wallet
}
Внизу есть база данных, которая в вашем случае является SQL. Это должно не подумайте, посмотрите на ваше приложение.
Делая предположения о зависимостях, выходящих за рамки того, что они гарантируют, в форме контрактов на интерфейс необратимо связывает компоненты
Это означает, что если вы моделируете свое приложение по схеме вашей базы данных, вы делаете это неправильно, потому что все ваше приложение теперь тесно связано с указанной базой данных, и любое изменение в любой ее части будет иметь большое, непредсказуемое влияние.
Распространенным решением является использование так называемого Слой ORM, который находится между вашим драйвером базы данных и моделями сущностей. Он позаботится о таких вещах, как:
- как и когда следует покупать кошельки?
- где в базе данных хранится информация кошелька?
- при удалении пользователя кошелек тоже должен быть удален?
между прочим
PS: Этот ответ относится как к статически, так и к динамически типизированным языкам.
Другие решения