Приводит ли JOIN в базе данных к дублированию кода в приложении?

Question

Например, у нас есть веб-приложение, которое использует PostgreSQL. В приложении есть AuthorService, который реализует операции CRUD для объекта Author. AuthorService использует таблицу «авторы» в базе данных.

Теперь нам нужно реализовать BookService, который должен извлекать данные из таблицы «books». BookService должен присоединиться к сущности Author.

Если мы используем SQL JOIN в BookService, то нам нужно повторить некоторый лог c (код) из AuthorService в BookService, поскольку AuthorService содержит доступ управляющие логи c для объекта Author и логи c для генерации URL-адресов фотографий автора (S3-подпись URL)

ИЛИ мы можем использовать AuthorService внутри BookService для извлечения данных и после того, как мы можем присоедините эти данные в приложении вместо PostgreSQL (мы можем написать al oop, объединяющий сущности), но в этом случае у нас могут возникнуть проблемы с производительностью.

Какой вариант лучше?

Answer 1

Я чувствую, что правильное место для выполнения JOIN находится в базе данных, даже если это может означать дополнительный код, необходимый со стороны приложения, как вы сказали.

Объединение на уровне приложения исключит любые оптимизации базы данных, которые может использовать оптимизатор базы данных, если "join" находится внутри БД. База данных оптимизатора выбирает вариант возврата обратных записей на основе статистики по значениям таблиц / столбцов / гистограмм и целого ряда оптимизаций.

Возьмем, к примеру, циклические логи c. Если у нас есть маленькая таблица с именем dept и большая таблица с именем emp и если мы хотим выполнить объединение запросов для двух в БД. Скорее всего, он будет использовать вложенный l oop, что может быть более эффективным, поскольку большую таблицу необходимо пройти всего один раз, чтобы получить все соответствующие записи. А если таблица dept широкая (много столбцов), оптимизатор может выбрать: используйте индекс и получите тот же результат эффективным способом

В случае, если обе таблицы велики, оптимизатор может выбрать соединение ha sh или сортированное соединение.

Рассмотрим альтернативу, в вашем приложении, если вы хотите присоединиться, вы будете использовать только циклическую логику c все время (в основном вложенную l oop) или если вы хотите реализовать сложный алгоритм выполнения "соединения", вы бы дублирование всех усилий, затраченных на создание базы данных.

Так что, на мой взгляд, лучший вариант - использовать дб для любых операций, связанных с SET (JOIN, FILTER, AGGREGATION)