Сортировка: OrderBy и Sort

1. Сортировка как контракт репозитория

Если вы когда-нибудь видели список товаров, который «прыгает» между перезапусками приложения, — поздравляю, вы встречались с отсутствием сортировки. База данных не обязана возвращать строки в «красивом» порядке. Она обязана вернуть правильный набор данных, а порядок без ORDER BY — это чаще всего “как получилось сегодня”. Поэтому сортировка в backend-коде — это не эстетика, а часть контракта чтения: мы обязаны явно сказать, какой порядок считаем корректным для данного use case.

Чтобы не было ощущения, что это “придирка преподавателя”, представьте очередь в кофейне. Если бариста говорит: «Я обслужу всех, кто в помещении», но не говорит “по очереди”, начнётся очень творческий режим: кто громче — тот и латте получает быстрее. Запрос без ORDER BY — примерно такая очередь, только в роли “громких” выступают планировщик запросов, текущий план выполнения и состояние индексов.

В SQL это выглядит просто: сортировка живёт в ORDER BY, и пока вы его не написали (или пока Spring Data не сгенерировал его за вас), порядок не гарантирован.

2. Два подхода: OrderBy... и Sort

Когда мы делаем derived query, у нас появляется два удобных способа сказать Spring Data: «верни, пожалуйста, данные в таком порядке». Оба способа хороши, просто решают разные задачи. Один — “зашить порядок в контракт”, другой — “разрешить вызывающему коду выбирать сортировку при вызове”.

Для начала — маленькая карта решений (без попытки превратить лекцию в справочник):

Дальше разберём оба по-человечески и на коде нашего mini-shop.

3. Фиксированная сортировка: findByStatusOrderByCreatedAtDesc(...)

Фиксированная сортировка — это когда вы заранее понимаете: сценарий всегда читает данные в одном порядке. Например, «покажи активные товары — сначала самые новые». В таком случае удобно прямо в имени метода выразить сортировку, и тогда любой разработчик (включая вас через две недели) видит её без поиска по сервисам и конфигам.

Синтаксис у derived queries очень буквальный: вы добавляете OrderBy, затем имя поля, затем направление Asc или Desc. Пример для нашего каталога — “новые активные товары”:

import org.springframework.data.jpa.repository.JpaRepository;

import java.util.List;

public interface ProductRepository extends JpaRepository<Product, Long> {

    // Сортировка "зашита" в контракт метода: кто бы ни вызвал — порядок всегда один и тот же
    // createdAt — поле entity (не имя колонки). Spring Data под капотом добавит ORDER BY ... DESC.
    List<Product> findByStatusOrderByCreatedAtDesc(ProductStatus status);
}

Здесь createdAt — это поле entity, а не колонка created_at. Spring Data построит запрос, в котором появится ORDER BY createdAt DESC (на SQL-уровне это станет order by created_at desc, но мы с вами мысленно всегда держим “entity ↔ table”).

Почему это удобно именно как контракт? Потому что метод называется так, что трудно использовать неправильно. Ты вызываешь findByStatusOrderByCreatedAtDesc(ACTIVE) — и получаешь активные товары строго в этом порядке. Никаких дополнительных аргументов, никаких “а как тут сортировать?”. Такой метод хорошо подходит для кусочков кода, которые являются “опорными” для проекта.

Но есть и обратная сторона: если через пару дней вы захотите “активные товары, но по цене”, то этот метод вам уже не поможет. И это нормально: фиксированная сортировка — как фиксированный маршрут автобуса. Он прекрасен, пока вам надо именно на этой линии, и раздражает, если внезапно захотелось в соседний район.

4. Динамическая сортировка через Sort

Теперь перейдём к сценарию, который встречается в реальности чаще: “дай товары по фильтру, но я хочу выбрать сортировку”. Даже если сейчас у нас нет web-layer, сервисный слой всё равно может иметь разные бизнес-методы: где-то сортируем по цене, где-то — по имени, где-то — по новизне. И переписывать под каждый порядок отдельный метод репозитория — это путь к маленькому монстру из методов.

Для этого Spring Data предлагает параметр Sort. Вы добавляете его в сигнатуру derived query, и он превращается в ORDER BY на стороне SQL.

Минимальный пример в репозитории:

import org.springframework.data.domain.Sort;
import org.springframework.data.jpa.repository.JpaRepository;

import java.util.List;

public interface ProductRepository extends JpaRepository<Product, Long> {

    // Сортировку выбирает вызывающий код: Sort будет превращён в ORDER BY на SQL-уровне
    // Важно: сортировка идёт по свойствам entity, а не по именам колонок таблицы.
    List<Product> findByStatus(ProductStatus status, Sort sort);
}

То есть у нас есть один метод, а порядок выбирает вызывающий код.

4.1. Сборка Sort в коде

Sort собирается из property-имен entity. Это важная мысль: мы сортируем по "price", "createdAt", "name", "id", а не по "price_amount" и не по "created_at".

Пример: “активные товары, сначала дорогие”. Мы добавим второе поле сортировки по id, чтобы порядок был стабильнее (про это чуть ниже).

import org.springframework.data.domain.Sort;

// "price" и "id" — это имена полей в entity, а не колонки в БД
Sort sort = Sort.by("price").descending()
        // Второй ключ сортировки делает порядок устойчивым при одинаковых значениях price
        .and(Sort.by("id").ascending());

List<Product> products =
        // Репозиторий получает уже готовое правило сортировки
        productRepository.findByStatus(ProductStatus.ACTIVE, sort);

Здесь идея простая: сначала сортируем по цене убывания, а если цены одинаковые — по id возрастанию. Это не “фишка для зануд”, а практический способ избежать ситуации, когда товары с одинаковой ценой каждый раз идут в новом порядке.

4.2. Где собирать Sort

Репозиторий — это “доступ к данным”, а сервис — это “use case”. А сортировка — это часть use case. Поэтому обычно Sort собирается на уровне сервиса.

Например, в CatalogService (который мы начали делать ранее) можно оформить метод “найди активные товары по цене” так:

import org.springframework.data.domain.Sort;

import java.util.List;

public List<Product> findActiveProductsByPriceDesc() {
    // Сервис фиксирует бизнес-смысл: какой порядок "правильный" для данного use case
    Sort sort = Sort.by("price").descending()
            // Добавляем второй ключ, чтобы результат не "плавал" при одинаковых ценах
            .and(Sort.by("id"));

    // Репозиторий остаётся универсальным: принимает фильтр + правило сортировки
    return productRepository.findByStatus(ProductStatus.ACTIVE, sort);
}

Да, это выглядит чуть “многословно” (всего-то сортировка!), но зато у вас есть понятное место, где написано, почему именно такой порядок считается правильным. Репозиторий остаётся универсальным, сервис — прикладным.

5. Полезные нюансы сортировки

5.1. Сортировка в памяти после репозитория

У новичков часто возникает мысль: «Ну я же могу получить список, а потом отсортировать его через products.sort(...)». И технически вы действительно можете. Проблема в том, что вы делаете это ценой трёх неприятных вещей: вы больше читаете из базы, чем нужно; вы нагружаете JVM лишней работой; и вы постепенно приучаете проект к привычке “вытащим всё, а потом разберёмся”.

Вот типичный “как делать не надо” вариант:

import java.util.Comparator;
import java.util.List;

List<Product> products = productRepository.findByStatus(ProductStatus.ACTIVE);

// Сортируем в памяти: это может быть дорого по CPU и памяти при больших объёмах
// А ещё вы заранее загрузили "всё", хотя база могла бы отсортировать и отдать нужное эффективнее
products.sort(Comparator.comparing(Product::getPrice).reversed());

На маленьком наборе данных это выглядит безобидно. На реальной базе (где активных товаров может быть много) — это путь к тому, что вы будете вытаскивать сотни/тысячи строк ради того, чтобы потом их отсортировать в памяти. База данных умеет сортировать эффективнее, и именно для этого существует ORDER BY.

Кроме того, сортировка в памяти плохо сочетается с дальнейшим развитием проекта: как только появятся ограничения по объёму чтения (а они появляются почти всегда), сортировать нужно будет уже “на стороне базы”, то есть вам всё равно придётся переехать на Sort/OrderBy.

5.2. Стабильный порядок: второй ключ сортировки

Стабильность порядка — это когда два одинаковых запроса возвращают данные в одном и том же порядке. Это важно не только для “красоты”, но и для предсказуемости. Если ваш основной ключ сортировки не уникален (например, у товаров часто одинаковая цена или одинаковая дата создания), то порядок может “плавать” внутри группы одинаковых значений.

Самый простой и рабочий приём — добавлять второй ключ сортировки: обычно id. Это почти всегда уникально и почти всегда есть в каждой сущности.

Выглядит так:

import org.springframework.data.domain.Sort;

// Первый ключ: "новые сверху"
Sort sort = Sort.by("createdAt").descending()
        // Второй ключ: фиксируем порядок внутри одинакового createdAt
        .and(Sort.by("id").descending());

List<Product> products =
        // Оба ключа превращаются в ORDER BY created_at DESC, id DESC
        productRepository.findByStatus(ProductStatus.ACTIVE, sort);

Здесь я специально сортирую id тоже по убыванию: когда товары созданы “в один момент” (для базы это может быть одна и та же секунда), более поздние вставки обычно будут иметь больший id. Но это не догма — вы выбираете направление так, чтобы оно соответствовало вашему бизнес-смыслу.

5.3. Как это выглядит в SQL

Чтобы окончательно выбить из головы идею “Sort — это Java-объект, а где-то там магия”, полезно представить, что происходит под капотом. Схематично это выглядит так:

flowchart TD
    S[CatalogService] --> R[ProductRepository method]
    R --> D[Spring Data JPA]
    D --> Q[SQL с ORDER BY]
    Q --> P["PostgreSQL"]
    P --> D
    D --> R
    R --> S

Sort превращается в ORDER BY примерно таким образом (условный пример для status = ACTIVE и сортировки по цене вниз):

-- База данных применяет фильтр и сортировку: порядок — часть результата, а не "удача"
select p.*
from product p
where p.status = ?
-- Два ключа сортировки: сначала по цене, затем для стабильности по id
order by p.price desc, p.id asc

Важно, что порядок результатов — это обязанность базы, а не случайность Java-кода. Поэтому сортировку лучше задавать на том же уровне, где вы задаёте фильтр: в запросе. Spring Data даёт два удобных “пульта управления” (OrderBy... и Sort), но цель всегда одна — корректный ORDER BY.

6. Типичные ошибки при сортировке через OrderBy и Sort

Ошибка №1: полагаться на “естественный порядок” результата без ORDER BY.
Иногда кажется, что “ну ведь обычно возвращается по id”. Это ощущение может держаться неделями… пока однажды не поменяется план выполнения запроса, не появится индекс, или вы не перезапустите контейнер базы. Без сортировки вы не покупаете контракт порядка, вы берёте лотерейный билет. Иногда выигрываете, но чаще просто не замечаете, что уже проиграли.

Ошибка №2: сортировать в памяти после загрузки данных.
На учебной базе это работает. На реальной — сначала работает, потом начинает тормозить, потом начинает “подъедать” память, а потом вы внезапно понимаете, что читаете в JVM гигантские списки только ради того, чтобы отсортировать их компаратором. Сортировка должна происходить там, где находятся данные — в БД.

Ошибка №3: передавать в Sort.by(...) имя колонки, а не имя поля entity.
Sort.by("created_at") выглядит логично, если вы думаете SQL-терминами. Но Spring Data сортирует по entity-свойствам. Вам нужно Sort.by("createdAt"). Это типичная “ORM-путаница”: вы уже живёте в мире entity, но в голове всё ещё звучит SQL.

Ошибка №4: не добавлять второй ключ сортировки при неуникальном поле.
Если вы сортируете только по price, то товары с одинаковой ценой могут оказаться “в произвольном порядке”. Это выглядит как дрожащий UI: пользователь открыл список — порядок один, обновил — другой. Добавление второго ключа (часто id) делает порядок устойчивым и снижает количество странных вопросов в духе “а почему у меня товары прыгают?”.

Ошибка №5: собирать Sort из произвольных строк без контроля.
Sort.by(userInput) кажется быстрым решением, пока userInput не станет "dropDatabase" (шутка) или просто "prcie" (опечатка, уже не шутка). Тогда вы получите ошибку во время выполнения, и она будет выглядеть как “всё сломалось”. Даже если вы пока не пишете web-layer, привычку лучше выработать сразу: сортировку строим из ограниченного набора допустимых вариантов, а не из “любой строки мира”.