Сводные таблицы или динамическое агрегирование

Question

У меня есть приложение, построенное с помощью php mysql, которое обрабатывает счета субподрядчиков для моей компании.

Мой вопрос такой.

Допустим, у меня есть 3 различных типа счетов, которые все рассчитываются (суммируются) по-разному в зависимости от типа. Кроме того, тип возвращаемой суммы зависит от привилегии авторизованного пользователя.

Итак, я пытаюсь обсудить лучший способ справиться с этим:

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

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

Или я склоняюсь к использованию различных сводных таблиц, которые создаются / обновляются при создании / обновлении счета-фактуры, а также к созданию представлений в mysql для управления их возвратом. Я думаю, что это будет лучше, но я не уверен. Это приведет к тому, что процесс отображения станет более сложным, но это позволит всей бизнес-логике остаться в моих классах php, и мой выбор SQL будет упрощен.

Поэтому, прежде чем я что-то сделаю, я просто хотел получить какой-то другой вклад.

Спасибо, Джон

Answer 1

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

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

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

Можно поместить бизнес-логику в MySQL, если это действительно единственный способ сделать запрос быстрым.Но, вообще говоря, избегайте этого.