Бизнес логика на хранимой процедуре

Question

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

У меня есть таблица типа: Items(item_id, itemd_name, item_price) с 700 предметами в ней.

Теперь я хочу показать клиенту все предметы и их названия. Поскольку я занимаюсь веб-разработкой, я не хочу загружать все 700 элементов, но использую подкачку - 40 элементов за раз.

(Когда я пишу «load», я имею в виду, что хранимая процедура возвращает datatable, а написанный мной код преобразует каждую строку в класс элемента - поэтому я не хочу загружать 700 элементов, она обрабатывает много данных Мне не очень нужно)

Итак, я написал хранимую процедуру, которая знает, как получить 40 элементов.

Теперь мне нужно суммировать все цены на товары и добавить 16% налог.

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

Единственное решение, которое я нашел, - это использовать другую хранимую процедуру, которая будет возвращать цену + сумму налога.

Answer 1

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

Первый: отобразить страницу данных с заданным смещением и размером страницы. Второй: отображать сводку данных в соответствии с некоторыми правилами.

И то и другое можно сделать, если вы используете простой хранимый процесс, который просто получает все данные, и вы можете обрабатывать разбиение на страницы и суммирование на стороне приложения, и это будет соответствовать вашему правилу «нет логики в базе данных». Это не будет большой проблемой, если у вас есть 700 строк, однако, если это число исчисляется сотнями тысяч, у вас будет большое снижение производительности при загрузке и обработке тонн элементов, которые вам на самом деле не нужны.

Второй подход состоит в том, чтобы поместить логику подкачки в один процесс, а логику суммирования - в другой. Логика подкачки довольно общая, поэтому ее не нужно считать «бизнесом», но генерация сводки, чтобы быть полезной, должна включать в себя реальную бизнес-логику. Это будет работать с точки зрения производительности, но явно нарушает ваше правило.

Конечно, нет единого правильного ответа, но в большинстве случаев я не против поместить бизнес-логику в базу данных, потому что даже структура базы данных ограничена бизнес-правилами системы. Если мы хотим абсолютно «не иметь бизнес-правил в базе данных», нам следует отказаться от значений по умолчанию, проверить ограничения и т. Д., Поскольку они также являются бизнес-ограничениями для данных, а не являются свойствами самих данных.