Следует ли моделировать большие отношения в объекте с точки зрения читабельности и производительности

Question

У меня есть объект, имеющий отношение к очень большой таблице (> 100 тыс. Строк). Теперь я спрашиваю себя, должен ли я действительно выражать это отношение в моей сущности канала, потому что никогда не вызывал бы getProducts напрямую для загрузки всех продуктов в память. Я бы предпочел пройти через репозиторий продуктов и запросить очень специфическое подмножество для этого канала.

Я только поместил его туда, чтобы он был более читабельным с точки зрения клиента.

@Entity
@Table(name = "Channel")
public class Channel {

    @OneToMany(fetch = FetchType.LAZY)
    @JoinColumn(name = "product_id")
    private List<Product> products;

    public void setProducts(List<Product> products) {
        this.products= products;
    }

    public List<Product> getProducts() {
        return this.products;
    }

}

Answer 1

Не помещайте это в определение сущности вообще. Вы видите, что часто пропускают, это имя @OneToMany очень вводит в заблуждение. Так как нет возможности ограничить количество загружаемых товаров. Практически его можно использовать только тогда, когда Много значит Мало :). Гибернатный Гуру объясняет лучше, чем я

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

Другая сторона уравнения более полезна. Так что, если у вас есть на аннотации дочерней сущности @ManyToOne, оставьте ее там. Хорошо, если вы обновляете родителя из контекста ребенка.

Answer 2

Короче говоря: нет.

Я думаю, что то, о чем вы спрашиваете, может быть основано на мнении, но вот что я склонен делать: убрать все "несудоходные" отношения.

Если вы используете какой-либо генератор для получения сущностей JPA из модели базы данных, генератор будет создавать только двунаправленные связи. Вам необходимо удалить все отношения, которые вы не будете использовать через механизмы ORM (для удобства чтения, поддержки и производительности (в случае, если у кого-то возникнет идея удалить «ленивое» указание или вызвать метод получения в коллекции в транзакции)) .

Например, пользователь будет связан с языком (многие-к-одному), но вы не хотите (один-ко-многим) отношения между языком и пользователем, даже если в какой-то момент вам понадобится знать на экране отчета, сколько пользователей говорят на каком языке.