Есть еще postGIS — тоже посмотрите. Т.к. работа с данными — это специализация PG (и вообще баз данных), то именно на это и делается акцент, плюс расширения постоянно разрабатываются.
. Скажите, сколько RPS вы потеряете на перепланировании запроса? Вы считали?
Если сам запрос хорошо оптимизирован и быстро выполняется, то на планирование может уйти процентов 30 общего времени.
Это не самая большая проблема. Модель, когда сырые данные сначала мелкими запросами поступают в переменные, потом эти переменные обрабатываются, потом дергаются новые запросы и т.д. до 100! раз снижает производительность (может и больше, но пока не встречал)
как огромную хэшмапу хэшмап.
Не знаю, кто такую хранит.
Хранимка возвращает конкретный ответ в соответствии со спецификацией API. Надо расширить => обновляем спецификацию => добавляем несколько строк в одной! хранимке, которая за этот вызов отвечает.
Если из них вырастает монолит на миллионы строк кода, зачем тогда ваш подход использовать?
Монолит вырастает, если делать множество мелких запросов и обрабатывать сырые данные в PHP. Пример выше очень простой. Для более сложной задачи (например, отобразить страницу как эта на хабре) потребуется гораздо больше запросов. Так вот, в рамках SQL это вполне можно уместить в один качественный запрос, и сразу вернуть json, на базе которого будет построена страница. Навскидку в пределах 500 строк будет хранимка.
Спорят с тем, откуда их вызывать — из базы или из приложения.
Да, вот и у меня вопрос — зачем из приложения запрос запускать, если он все равно в базе выполняется? Это как просить соседа открывать вам дверь, хотя можете и сами открыть ключом.
У вас 2 запроса
У меня один запрос, планировщик его один раз прогнал, и более того план сохранил — больше не будет дергаться. И чем сложнее запрос, тем больше будет различие в скорости.
SQL с EXPLAIN нормально с этим справляется.
Так если Вы все равно лезете в базу и оптимизируете там запросы, то почему там сразу весь код не сделать?
запросы тестируете, вместо того, чтобы бизнес-логику писать)
Запросы и есть бизнес-логика) Они на входе берут параметры и на выходе дают ответ с данными.
Вы серьезно? Качество работы бэкенда Вас не беспокоит? Тогда видимо мы зря дискутируем)
А в вашем случае вы будете менять ответы пары десятков процедур, которые возвращают эту сущность.
Эту сущность возвращает ровно одна хранимка. Другие хранимки возвращают другие ответы в соответствии со спецификацией API
Классы затем и выделяют, что они являются основной единицей изменений.
Одни классы могут зависеть от других — это и есть зависимости. Плюс на базе класса можно создать много объектов — это тоже зависимости. Чем больше зависимостей в системе, тем менее она надежна.
Если у вас данные для связи таблиц записаны в JSON, это проблема вашей архитектуры.
Понятно — про SQL-NoSQL структуру видимо не слышали. Подпишитесь на наш блог — скоро будет подробная статья на эту тему.
просто вместо CTE переменные
В чем ценность данные сначала в переменные складывать, а потом в новый запрос пихать? Почему это нельзя сделать в рамках одного запроса?
JSON-данные парсить
Вы знаете косты на эту операцию? В PG в секунду около миллиона таких операций можно сделать, и это на одном процессоре. У Вас сколько запросов в секунду идет?
что небольшой дополнительный оверхед для удобства это нормально?
Конечно, нормально — если он небольшой, а не десятикратный. Замена оптимизированного SQL-запроса из 10 CTE's на десять маленьких запросов с сохранением данных в переменную ухудшает производительность до 100! раз (да, и такого добивался, объединив 10 простых селектов в нормальный запрос)
Как я написал выше, философия SQL и философия не-SQL языков сильно отличаются. И инструменты требуются совершенно разные.
Автокомплитом качественный SQL-запрос не напишешь. И анализ идет не кода, а самого запроса (для этих целей есть EXPLAIN ANALYZE).
Это примерно как сравнивать автомобиль и самолет: способы управления совершенно разные. Хотя и тот, и другой предназначен для перемещения в пространстве.
Для формирования HTML есть node.js и другие инструменты. Главное — как им предоставить нужные данные в json. Собственно, раньше почти весь код на PHP это и делал. Сейчас это делает SQL.
Давайте в личке обсудим Ваш проект — если Вы конечно заинтересованы посмотреть на него с другой стороны…
Можно одним запросам получить, например, список объектов с сортировкой по удалению от конкретной точки (или других объектов)
Если сам запрос хорошо оптимизирован и быстро выполняется, то на планирование может уйти процентов 30 общего времени.
Это не самая большая проблема. Модель, когда сырые данные сначала мелкими запросами поступают в переменные, потом эти переменные обрабатываются, потом дергаются новые запросы и т.д. до 100! раз снижает производительность (может и больше, но пока не встречал)
Не знаю, кто такую хранит.
Хранимка возвращает конкретный ответ в соответствии со спецификацией API. Надо расширить => обновляем спецификацию => добавляем несколько строк в одной! хранимке, которая за этот вызов отвечает.
Монолит вырастает, если делать множество мелких запросов и обрабатывать сырые данные в PHP. Пример выше очень простой. Для более сложной задачи (например, отобразить страницу как эта на хабре) потребуется гораздо больше запросов. Так вот, в рамках SQL это вполне можно уместить в один качественный запрос, и сразу вернуть json, на базе которого будет построена страница. Навскидку в пределах 500 строк будет хранимка.
Да, вот и у меня вопрос — зачем из приложения запрос запускать, если он все равно в базе выполняется? Это как просить соседа открывать вам дверь, хотя можете и сами открыть ключом.
У меня один запрос, планировщик его один раз прогнал, и более того план сохранил — больше не будет дергаться. И чем сложнее запрос, тем больше будет различие в скорости.
Так если Вы все равно лезете в базу и оптимизируете там запросы, то почему там сразу весь код не сделать?
Запросы и есть бизнес-логика) Они на входе берут параметры и на выходе дают ответ с данными.
Вы серьезно? Качество работы бэкенда Вас не беспокоит? Тогда видимо мы зря дискутируем)
Эту сущность возвращает ровно одна хранимка. Другие хранимки возвращают другие ответы в соответствии со спецификацией API
Одни классы могут зависеть от других — это и есть зависимости. Плюс на базе класса можно создать много объектов — это тоже зависимости. Чем больше зависимостей в системе, тем менее она надежна.
Понятно — про SQL-NoSQL структуру видимо не слышали. Подпишитесь на наш блог — скоро будет подробная статья на эту тему.
В чем ценность данные сначала в переменные складывать, а потом в новый запрос пихать? Почему это нельзя сделать в рамках одного запроса?
Вы знаете косты на эту операцию? В PG в секунду около миллиона таких операций можно сделать, и это на одном процессоре. У Вас сколько запросов в секунду идет?
Конечно, нормально — если он небольшой, а не десятикратный. Замена оптимизированного SQL-запроса из 10 CTE's на десять маленьких запросов с сохранением данных в переменную ухудшает производительность до 100! раз (да, и такого добивался, объединив 10 простых селектов в нормальный запрос)
Автокомплитом качественный SQL-запрос не напишешь. И анализ идет не кода, а самого запроса (для этих целей есть EXPLAIN ANALYZE).
Это примерно как сравнивать автомобиль и самолет: способы управления совершенно разные. Хотя и тот, и другой предназначен для перемещения в пространстве.
Давайте в личке обсудим Ваш проект — если Вы конечно заинтересованы посмотреть на него с другой стороны…
В PG нужны средства отладки запросов — это не построковая операция. Для этих целей есть EXPLAIN ANALYZE и сопутствующие утилиты