Бэкенд или фронтенд должен объединять таблицы по FK?

Question

[vi0]

В бэкенде сервиса есть две таблицы БД связанные отношением один ко многим.

table1
- PK: int
- name: string

table2
- PK: int
- name: string
- FK: table1

В сервисе есть API позволяющие получить данные этих таблиц на фронтенд.

Если требуется вывести на фронтенде данные обеих таблиц в объединенном виде по FK, то какие могут быть причине не делать новый API который даст эти данные в нужном виде:
t1.name, t2.name

Т.е. какие могут быть причины, чтобы фронтенд получал данные таблиц из существующих API и сам делал объединение таблиц?

Answer 1

[alexalexes]

Дело в количестве записей.
Если пересылка запросов отдельно для данных table1 и table2 стоит дороже, и объединение записей на клиенте работает хуже чем индекс в базе данных по FK, то вам нужен отдельный запрос с объединенными данными.
Если результирующих записей мало, что они никак не влияют на производительность, то делайте как угодно.
Есть еще аспект стоимости нагрузки сервера и клиента. Нагрузка сервера - это ваши издержки, нагрузка клиента - пользователя. Ваши возможности - конечны, а у пользователя - как правило с запасом. Если клиентов много у вашей системы, то с этой точки зрения тоже нужно искать баланс.

Answer 2

[Aetae]

Если работа идёт всегда со всеми данными - отдельный бэк api не нужен.
Если работа идёт с какой-то определённой выборкой(как бывает в 99% случаев), то запрос в любом случае нужен, потому что, чтобы получить соответствующие выборке значения из соседней таблицы, клиенту потребуется посылать уже массив id, что, внезапно, увеличит накладные расходы бэка, по сравнению с простеньким join'ом потребным для спец-api.

Answer 3

[Dmitry Roo]

Нет никаких причин оперировать понятиями бд на фронт-энде.

Comments

[alexalexes]

Тут скорее, как работать с API от двух "справочников", то что они могут получаться из отдельных таблиц - частный случай.