Вы правы насчет времени обработки (а также ресурсов, таких как память).
- Передовой опыт заключается в агрегировании максимально возможного количества данных, в идеале в базе данных. Сотни миллионов объектов кажутся сумасшедшими.
- Тем не менее, мы все знаем, что этот код менее удобен в обслуживании. Так что больше времени на разработку и больше затрат в конце.
Так что вам нужно достичь правильного баланса. Это не может прийти к вам извне,
вы должны тщательно взвесить преимущества в конкретном контексте вашего проекта .
Например, частота все это имеет большое значение. Высокая стоимость, очевидно, приемлема, если процесс происходит каждую минуту, но, вероятно, нет, если это происходит каждый год ...
Может быть, правильный баланс потребовал бы и того, и другого. Например, для хорошего ROI:
- запросы к базе данных могут выполнять первый уровень агрегации, избавляясь от мельчайших деталей и уменьшая количество создаваемых объектов на сотню.
- бизнес-уровень может применять остальные правила
Что делает хорошим кандидатом требование, о котором заботятся в запросе:
- агрегация низкого уровня, которая уменьшает количество объектов (или строк), которые выходят из базы данных
- правила, которые редко меняются
- правила, которые легко читаются в SQL
Чтобы сделать ваш код более явным (и уменьшить дублирование между запросами), я предлагаю, чтобы ваш код принял структуру времени компиляции, которая проясняет его. Создайте явные константы или функции, которые воплощают каждое бизнес-правило, которое вы поместите в запрос, и используйте его для построения (во время выполнения или во время компиляции) ваших запросов.