Компонентация большого нечитаемого запроса SQL делает его слишком медленным, но отсутствие централизованных определений концепций оказывается опасным
Я изо всех сил пытаюсь понять, как написать код, который достаточно быстр для выполнения поставленной задачи, но который также хорошо структурирован, чтобы его можно было читать и поддерживать в будущем.
Задача состоит в том, чтобы создать отчет о продажах в php, который опирается на данные из базы данных SQL. Этот отчет возвращает тысячи строк, каждая из которых представляет продажу. Многие столбцы отчета должны быть вычислены во время создания отчета, поскольку их значения не сохраняются в базе данных. Я написал один большой запрос SQL, который генерирует отчет за один раз очень быстро.
Моя проблема в том, что это создает дублирование кода, и, кроме того, кому-то будет очень трудно понять код SQL с точки зрения системных объектов. Например, в моей библиотеке функций есть функция, которая возвращает сумму денег, полученную за продажу. Для этого он вызывает следующий фрагмент SQL.
SELECT SUM(amount) AS amount_received
FROM transactions
WHERE
tran_status = 'Success' AND
booking_id = $booking_id
При создании отчета слишком медленно вызывать эту функцию один раз для каждой отдельной продажи после того, как я получу тысячи продаж из базы данных. Поэтому вместо этого я присоединяюсь к следующему оператору SELECT, чтобы продажи поступали из базы данных со столбцом amount_received.
SELECT booking_id, SUM(amount) AS amount_received
FROM transactions
WHERE tran_status = 'Success'
GROUP BY booking_id
Когда я писал этот отчет, я делал это с помощью множества различных системных понятий, и я знаю, что опасно иметь такие ключевые понятия, определенные более чем в одном месте, и что даже я изо всех сил пытаюсь прочитать мой массивный запрос SQL. Любой совет будет принята с благодарностью.
Это мой первый вопрос, извините, если я сделал что-то не так …
Решение
Показать полный запрос и выполнить полный запрос в pma с ведущей строкой «EXPLAIN»;
Другие решения
Это похоже на проблему N + 1 Query. Отчет будет отдельным объектом, независимо от того, что вы делаете, и потребует дополнительной структуры. Подумайте о создании управляемых множествами альтернатив вашим запросам отдельных объектов и включите их в многообъектные наборы, будь то массивы или какая-либо другая структура выбора. Сделайте его достаточно гибким, чтобы брать кучу идентификаторов, а затем передавать эти идентификаторы различным компонентам для получения данных. Затем вы можете перебирать огромные множества, чтобы рассчитать то, что вам нужно. Примечание: этот подход требует большого объема памяти, потому что вы сохраняете много данных, прежде чем касаться их, выводить их и т. Д. Я рекомендую возвращать наборы результатов вместо заполненных массивов — так или иначе эта память будет использоваться на сервере SQL.
Таким образом, вы получаете свои определения, у вас есть более быстрое (но все еще не оптимальное) решение, и тогда отчеты — это объекты, которые показывают, как вы выполняете, какие наборы результатов и состав отчета на странице.