Pull to refresh
32
0
Lingualeo.com @LinguaLeo

Пользователь

Send message
Добрый день! Мы проверили ситуацию, описанную пользователем в этом треде. Указанные им факты не подтвердились.
По мобильной разработке ранее активно использовали аутсорс, сейчас полностью своя команда работает. Поэтому и набирали мобильных разработчиков
Никакой ошибки нет. Скоро будет цикл статей на эту тему
Так вот из таких простых селектов потом и вырастает монолит на миллионы строк кода. И сервера жрет немеренно. Идея современного SQL — в том, чтобы писать эффективные запросы, причем достаточно быстро, отлаживать их, оптимизировать.

Дроблением на простые запросы этого не решишь — наоборот, только усложнишь разработку и производительность снизишь в десятки раз.

При работе с данными 90+% времени уходит на тестирование запросов: какие планы они используют, насколько быстро выполняются. Какие для этого есть средства в PHP?
«Сложный» — понятие относительное. Главное, что он один, и не требуется под каждую задачу писать новый.

Вот тут привели пример решения задачи выше на PHP:
habr.com/ru/post/515628/#comment_21977132

Есть что сравнивать. И это на очень простой задаче… По мере роста сложности пропасть растет в геометрической прогрессии.
Так никто и не мешает их банкам использовать. Хранимка — это такой же микросервис, с 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-ответ, т.е. статус, заголовки и тело ответа.
habr.com/ru/company/lingualeo/blog/515530/#comment_21976428

Продемонстрируйте, пжл
Вот тут все наглядно продемонстрировано:
habr.com/ru/company/lingualeo/blog/515530/#comment_21976428

(сравните мой пример и пример ниже на PHP)

В итоге PHP (или другой язык) просто дергает грамотный SQL-запрос, написанный специалистом. Вопрос ценности такой прослойки у меня и вызывает сомнения.

Я привожу конкретные примеры. Приведите, пжл, тоже примеры, когда использование PHP для обработки данных дает какие-либо преимущества.
Все верно.

Главное — это уйти от попыток решать SQL-задачи средствами не-SQL языков. Тогда скорость и качество разработки вырастут в разы (и десятки раз).

Продолжение следует…
В нашем случае необходимость в таком слое просто отпала. Система стала заметно проще и прозрачнее. Сейчас весь код бэкенда — это 200 микросервисов, из которых 180 — это хранимки.
Прокси передает только json. Обработка http — это на его стороне. Все хранимки — это строго json-вход, json-выход. Без вариантов
SQL стал гораздо шире, чем просто SELECT/WHERE/GROUP BY

Поэтому сейчас и появилась возможность его активно использовать для 95+% задач по работе с данными. 10 лет назад не было для этого возможностей.

Не поленитесь, попробуйте сами одну-две функции на современном SQL написать. Это реально сдвиг сознания, что с данными можно по-другому работать.

Надеюсь, хватит сил в выходные написать статью с примерами хранимок (и самое главное с примерами их развития с учетом растущих требований проектов). Кидайте идеи, какую проблему будем решать (платежи, емейлинг, ...)
Совершенно верно! Приношу всем извинения, если ввел в заблуждение фразами типа «всю логику перенесли в базу». В базе только логика работы с данными через SQL.

Каждому языку есть своя ниша. Главное — использовать по назначению.
Насчет гибкого ответа — в комменте ниже.

Глобальные константы — это конфиг. Необходимые компоненты вычитываются при запуске хранимки простым селектом.

Таблица юзеров — это скорее исключение, но и структура ее меняется достаточно редко (при условии использования jsonb-поля внутри). А по более специализированным таблицам — да, 3 — 10 хранимок, не больше.
1
23 ...

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Registered
Activity