Вычисляемое поле против сложных запросов в базе данных (с использованием JPA)

Question

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

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

Это, очевидно, приводит к некоторым довольно сложным запросам только для получения текущего уровня запасов. Хуже того, мы используем JPA, который не может обрабатывать все это в QL, поэтому нам приходится использовать собственные запросы или запрашивать большие наборы результатов и обрабатывать результаты в приложении.

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

В какую сторону вы пойдете?

Answer 1

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

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

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

Answer 2

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

Answer 3

Пара идей для обдумывания:

У вас есть сущность StockLevel?

Очевидно, я не знаю, как выглядит ваша текущая модель / таблицы домена, но, возможно, у вас может быть сущность StockLevel:

// annotations not shown
public class StockLevel {
    private Item item;  // unidirectional one-to-one?
    private int inbound;
    private int outbound;
    public int getInbound ...
    public int getOutbound ...
    public int getLevel ... // derived from other two
    // setters
}

Вам необходимо убедиться, что сущность StockLevel всегда обновляется в той же транзакции, что и движения запасов? Однако эти StockLevel могут стать источником раздоров.

Использовать специфичное для БД решение

Вы можете рассмотреть возможность использования триггеров БД, чтобы избежать необходимости постоянно пересчитывать одно и то же число.

Вы также можете использовать хранимую процедуру, чтобы скрыть, как БД рассчитывает уровень запаса по своему вызывающему. Таким образом, вы можете начать с перемещения запроса в SP, а затем исследовать другие подходы, сохраняя тот же код приложения.