Должен ли бэкенд или фронтенд заниматься объединением таблиц на основе внешних ключей (FK)?

Question

Никита

фронтенд , api

Должен ли бэкенд или фронтенд заниматься объединением таблиц на основе внешних ключей (FK)?

В бэкенде сервиса имеется две таблицы базы данных, связанные отношением один ко многим: 

<pre><code>table1
- PK: int
- name: string

table2
- PK: int
- name: string
- FK: table1</code></pre> 

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

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

20 ноября 2024 г. 4:03

Ответы на вопрос 3

Похожие вопросы

Answer 1

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

1. **Производительность**:
   - Бэкенд может оптимизировать запросы к БД, выполняя необходимые JOIN-ы на сервере. Это позволяет уменьшить объем передаваемых данных, так как фронтенду не нужно загружать всю таблицу в память для выполнения объединения.
   - Выполнение объединений на стороне бэкенда обычно быстрее из-за меньшего объема данных, передаваемых по сети, и оптимизации на стороне базы данных.

2. **Сложность бизнес-логики**:
   - Если логика объединения данных становится сложной (например, включает в себя фильтрацию, агрегацию и т.д.), её реализация на стороне бэкенда может сделать код фронтенда проще и более понятным.
   - Бэкенд может предоставить единообразный интерфейс для получения различных представлений данных.

3. **Сложность фронтенда**:
   - Объединение данных на фронтенде требует дополнительных процессов и манипуляций с данными, что может усложнить код и повлиять на производительность клиентского приложения, особенно если данные большие.

4. **Безопасность**:
   - Бэкенд может более эффективно управлять доступом к данным, уменьшая риск утечек информации, которые могут возникнуть, если фронтенд получает доступ к нескольким API и обрабатывает данные самостоятельно.

5. **Совместимость и масштабируемость**:
   - Объединение данных на стороне бэкенда упрощает изменения и поддержание API в будущем. Если структуру данных или логику работы нужно изменить, это потребуется делать только в одном месте.

6. **Кэширование**:
   - На бэкенде легче работать с кэшированием объединенных данных, так как такие запросы могут быть кэшированы и повторно использованы для других клиентов, что повышает производительность.

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

Answer 2

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

Answer 3

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