EE
Size: a a a
2020 December 16
МФ
p.s. микрослужбы звучит забавно
АГ
SM
АГ
>_<
2020 December 17
АЯ
Приветствую. Подскажите плиз, как лучше.
Есть адрес доставки для заказа, есть шаблон адреса доставки. Поля у них одинаковые.
Как более правильно это должно было бы выглядеть?
1) 2 сущности, 2 таблицы. (Более за этот вариант, но не овер ли, с учетом одинаковых полей)
2) 2 сущности, 1 таблица (Single Table inheritance)
3) 1 сущность с булевым полем.
4) Другое?
Есть адрес доставки для заказа, есть шаблон адреса доставки. Поля у них одинаковые.
Как более правильно это должно было бы выглядеть?
1) 2 сущности, 2 таблицы. (Более за этот вариант, но не овер ли, с учетом одинаковых полей)
2) 2 сущности, 1 таблица (Single Table inheritance)
3) 1 сущность с булевым полем.
4) Другое?
разные
ПГ
АЯ
1?
ну конкретно адрес доставки и шаблон - это две разные сущности. друг с другом пересекающиеся только косвенно.
это если я правильно понял что за шаблон.
это если я правильно понял что за шаблон.
АЯ
а вот с всякими сингл тейбл инхеритансами и прочими я бы был поаккуратнее, может внезапно вылезти боком
ПГ
а вот с всякими сингл тейбл инхеритансами и прочими я бы был поаккуратнее, может внезапно вылезти боком
Ну вот у меня с этим и вопрос. Всегда есть вариант чутка запутаться в запросе и получить не ту "сущность". У нас уже вариант с булевым полем. Но мне он не нравится, вот думаю верно ли мыслю что не нравится или нет.
кейс в целом такой:
Клиент оформляет доставку, заполняет адресс и свои данные. И эти вот значения он может сохранить как шаблон для будущих доставок.
кейс в целом такой:
Клиент оформляет доставку, заполняет адресс и свои данные. И эти вот значения он может сохранить как шаблон для будущих доставок.
АЯ
вот этот шаблон
АЯ
тогда вообще никак не маркируй, это не шаблон - это инфа о доставке
SP
все так, есть некий скоуп shipping и "та часть которую ты хочешь реюзать" есть его часть.
SP
ну то есть грубо говоря структура данных shipping address как заказа так и "используемые адреса" это все часть одного модуля
АЯ
и булево поле тебе не надо. я бы просто сделал связь пользователь <=> инфа о доставке. и вот её значение использовал бы как данные для автозаполнения
SP
при этом важно что shipping address и billing address могут выглядеть похожим образом но не обязательно являются одним и тем же и возможно нужны разные структуры
АЯ
важно помнить, что не саму инфу о доставке и только её значения
АЯ
при этом важно что shipping address и billing address могут выглядеть похожим образом но не обязательно являются одним и тем же и возможно нужны разные структуры
мне кажется там фишка идёт просто "скопирнуть старые данные о доставке и дать их возможность отредактировать"
˸A
мне кажется там фишка идёт просто "скопирнуть старые данные о доставке и дать их возможность отредактировать"
Обычно так и делают. А ещё у юзера может быть уже сохранённый список адресов - и фиг поймёшь, какие из них доставка, какие биллинг. Я на этом "собаку съел" - с 2011 года е-коммерс пишу