SQL Join vs Separate Query в коде без соединения - производительность

Я хотел бы знать, есть ли действительно выигрыш в производительности между этими двумя параметрами:

Вариант 1:

Я делаю SQL-запрос с соединением для выбора всех пользователей и их рангов.

Вариант 2:

Я делаю один SQL-запрос, чтобы выбрать всех пользователей
Я получаю всех пользователей и делаю еще один SQL-запрос, чтобы получить звания этого пользователя.

В коде второй вариант легче реализовать для меня. Это только потому, что я создаю свой слой Persistence.

Итак, я хотел бы знать, какое влияние на производительность. После какого предела я должен рассмотреть вариант 1 вместо варианта 2?

Ответ 1

Вообще говоря, сервер БД всегда быстрее присоединяется, чем код приложения. Помните, что вам нужно будет сделать дополнительный запрос с круговой поездкой по сети для каждого соединения. Однако, если ваш первый набор результатов мал и ваши индексы хорошо настроены, эта модель может работать нормально.

Если вы делаете это только для повторного использования своего решения ORM, вы можете сражаться с проигранной битвой. Я всегда обнаружил, что мне нужны только данные для чтения, которые могут быть созданы только с помощью SQL, поэтому теперь я использую ORM для операций CRUD для каждого объекта и обычного SQL для поиска, отчетов, агрегатов и т.д.

Ответ 2

Если ранги являются статическими значениями, рассмотрите их кэширование в приложении.

Если вам нужны пользователи часто и ряды только редко, рассмотрите ленивую загрузку рангов. (например, отдельные запросы, но второй запрос используется только изредка).

Используйте соединение, если вам всегда понадобятся оба набора данных, и они должны быть текущими копиями базы данных.

Прототипируйте любые вероятные варианты и выполните тесты производительности.

EDIT: Дальнейшие мысли о вашем уровне персистентности, потому что я сам сталкиваюсь с этим. Подумайте о добавлении классов "persistence-like", которые обрабатывают объединения в качестве основного запроса и доступны только для чтения. Независимо от того, подходит ли это вашему конкретному сценарию, вы должны решить, но большой доступ к базам данных для многих приложений основан на объединениях, которые могут быть довольно большими и сложными. Если вы сможете обрабатывать их согласованно с вашими постоянными обновляемыми объектами, это может стать большой победой для вашей общей архитектуры. По идее, это очень похоже на просмотр в базе данных и запрос к представлению вместо написания соединения, но вы делаете все это в коде.

Ответ 3

Это зависит от того, сколько пользователей вы ожидаете. Вариант один определенно будет быстрее, но с разумным объемом данных разница будет незначительной.

Ответ 4

В 99% ситуациях соединение будет быстрее.

Однако есть одна редкая ситуация, когда она может быть медленнее. Если вы делаете одно со многими, подключайтесь к таблице с большим размером строки, и вы получаете ограничение пропускной способности сети.

Например, есть столбец blob в T1 размером 1 МБ, вы присоединяетесь к T2, которые состоят из 100 строк для каждой строки T1. Результирующим множеством будет количество строк T1, количество 100.

Итак, если вы запрашиваете одну строку T1 со входом, это будет 100MB результат, если вы выберете строку T1 (1MB), а затем сделайте отдельный выбор для извлечения 100 T2 для этого T1, результирующий набор будет 1MB.