Так вот из таких простых селектов потом и вырастает монолит на миллионы строк кода. И сервера жрет немеренно. Идея современного SQL — в том, чтобы писать эффективные запросы, причем достаточно быстро, отлаживать их, оптимизировать.
Дроблением на простые запросы этого не решишь — наоборот, только усложнишь разработку и производительность снизишь в десятки раз.
При работе с данными 90+% времени уходит на тестирование запросов: какие планы они используют, насколько быстро выполняются. Какие для этого есть средства в PHP?
Так никто и не мешает их банкам использовать. Хранимка — это такой же микросервис, с json-входом и json-выходом. Отличается о других только тем, что написан на SQL, а не PHP.
Не ставил целью изучить ИС банка: если Вы с ними работали, приведите аргументы, почему хранимки противопоказаны там.
1. Планировщик PG будет каждый раз ваш запрос перепланировать, тем более что там теперь два запроса.
2. Требуется прописывание доп. классов. Зачем? Завтра придут продакты, попросят еще 5 параметров включить. Будете класс переписывать? И все зависимости?
В моей случае это займет пару минут — в ответе дополнить 5 атрибутов.
3. А если запрос сложный, требуется получение данных из 5 таблиц, распаковка на лету json-данных из таблиц, использование этих данных в след. запросах?
Так никто и не запрещает пользоваться микросервисами на любом языке. Они должны дополнять друг друга, а не тянуть одеяло на себя.
В нашем проекте 95+% процентов задач бэка связаны именно с работой с данными, и для этих задач SQL подходит гораздо лучше любого не-SQL языка. Поэтому от PHP-кода в 1 млн строк осталось меньше 10К строк (и то почти весь на Go переписали)
Есть гипотеза, что множество других проектов также выиграют от такого маневра. Со своей стороны постараюсь наглядно показать его бенефиты
Прокси собирает GET/POST параметры, некоторые заголовки запроса (некоторые детали описываются в параметра мидлварок) и формирует из них json-структуру для запроса в хранимку, которая определяется роутером исходя из эндпоинта.
Статус ответа обычно 200 со структурой json и соответствующим Content-Type, описанной в документации, за исключением кейсов связанных неверным запросом или доступом (400/401/403). И конечно 5xx не исключение.
Сама хранимка отдает несколько больше полей в json для целей аналитики, прокси их вырезает и отправляет в сборщик аналитики в фоне, а на фронт летит то, что описано в документации ручки
Есть пара кейсов, где при помощи json описывается http-ответ, т.е. статус, заголовки и тело ответа.
В итоге PHP (или другой язык) просто дергает грамотный SQL-запрос, написанный специалистом. Вопрос ценности такой прослойки у меня и вызывает сомнения.
Я привожу конкретные примеры. Приведите, пжл, тоже примеры, когда использование PHP для обработки данных дает какие-либо преимущества.
В нашем случае необходимость в таком слое просто отпала. Система стала заметно проще и прозрачнее. Сейчас весь код бэкенда — это 200 микросервисов, из которых 180 — это хранимки.
SQL стал гораздо шире, чем просто SELECT/WHERE/GROUP BY
Поэтому сейчас и появилась возможность его активно использовать для 95+% задач по работе с данными. 10 лет назад не было для этого возможностей.
Не поленитесь, попробуйте сами одну-две функции на современном SQL написать. Это реально сдвиг сознания, что с данными можно по-другому работать.
Надеюсь, хватит сил в выходные написать статью с примерами хранимок (и самое главное с примерами их развития с учетом растущих требований проектов). Кидайте идеи, какую проблему будем решать (платежи, емейлинг, ...)
Совершенно верно! Приношу всем извинения, если ввел в заблуждение фразами типа «всю логику перенесли в базу». В базе только логика работы с данными через SQL.
Каждому языку есть своя ниша. Главное — использовать по назначению.
Глобальные константы — это конфиг. Необходимые компоненты вычитываются при запуске хранимки простым селектом.
Таблица юзеров — это скорее исключение, но и структура ее меняется достаточно редко (при условии использования jsonb-поля внутри). А по более специализированным таблицам — да, 3 — 10 хранимок, не больше.
Дроблением на простые запросы этого не решишь — наоборот, только усложнишь разработку и производительность снизишь в десятки раз.
При работе с данными 90+% времени уходит на тестирование запросов: какие планы они используют, насколько быстро выполняются. Какие для этого есть средства в PHP?
Вот тут привели пример решения задачи выше на PHP:
habr.com/ru/post/515628/#comment_21977132
Есть что сравнивать. И это на очень простой задаче… По мере роста сложности пропасть растет в геометрической прогрессии.
Не ставил целью изучить ИС банка: если Вы с ними работали, приведите аргументы, почему хранимки противопоказаны там.
1. Планировщик PG будет каждый раз ваш запрос перепланировать, тем более что там теперь два запроса.
2. Требуется прописывание доп. классов. Зачем? Завтра придут продакты, попросят еще 5 параметров включить. Будете класс переписывать? И все зависимости?
В моей случае это займет пару минут — в ответе дополнить 5 атрибутов.
3. А если запрос сложный, требуется получение данных из 5 таблиц, распаковка на лету json-данных из таблиц, использование этих данных в след. запросах?
В нашем проекте 95+% процентов задач бэка связаны именно с работой с данными, и для этих задач SQL подходит гораздо лучше любого не-SQL языка. Поэтому от PHP-кода в 1 млн строк осталось меньше 10К строк (и то почти весь на Go переписали)
Есть гипотеза, что множество других проектов также выиграют от такого маневра. Со своей стороны постараюсь наглядно показать его бенефиты
Статус ответа обычно 200 со структурой json и соответствующим Content-Type, описанной в документации, за исключением кейсов связанных неверным запросом или доступом (400/401/403). И конечно 5xx не исключение.
Сама хранимка отдает несколько больше полей в json для целей аналитики, прокси их вырезает и отправляет в сборщик аналитики в фоне, а на фронт летит то, что описано в документации ручки
Есть пара кейсов, где при помощи json описывается http-ответ, т.е. статус, заголовки и тело ответа.
Продемонстрируйте, пжл
habr.com/ru/company/lingualeo/blog/515530/#comment_21976428
(сравните мой пример и пример ниже на PHP)
В итоге PHP (или другой язык) просто дергает грамотный SQL-запрос, написанный специалистом. Вопрос ценности такой прослойки у меня и вызывает сомнения.
Я привожу конкретные примеры. Приведите, пжл, тоже примеры, когда использование PHP для обработки данных дает какие-либо преимущества.
Главное — это уйти от попыток решать SQL-задачи средствами не-SQL языков. Тогда скорость и качество разработки вырастут в разы (и десятки раз).
Продолжение следует…
Поэтому сейчас и появилась возможность его активно использовать для 95+% задач по работе с данными. 10 лет назад не было для этого возможностей.
Не поленитесь, попробуйте сами одну-две функции на современном SQL написать. Это реально сдвиг сознания, что с данными можно по-другому работать.
Надеюсь, хватит сил в выходные написать статью с примерами хранимок (и самое главное с примерами их развития с учетом растущих требований проектов). Кидайте идеи, какую проблему будем решать (платежи, емейлинг, ...)
Каждому языку есть своя ниша. Главное — использовать по назначению.
Глобальные константы — это конфиг. Необходимые компоненты вычитываются при запуске хранимки простым селектом.
Таблица юзеров — это скорее исключение, но и структура ее меняется достаточно редко (при условии использования jsonb-поля внутри). А по более специализированным таблицам — да, 3 — 10 хранимок, не больше.