Почему? Можно формировать ответ по запросу — буквально две строчки кода:

SELECT jsonb_object(key, jsrecord->(value))
FROM jsonb_each_text(ljAttrList)

Я ljAttrList кидаю маппинг (какие атрибуты с какими названиями вернуть), в jsrecord — атрибуты, которые хранимка использует.

Это поддержали, но по опыту не особо пригодилось: в API-документе прописаны нужные названия, их и придерживаемся. Надо добавить пару новых атрибутов — сразу в ответ и добавляем.

Логично, что мало смысла)

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

Собственно, об этом и статья — давайте данные обрабатывать в тех системах, которые для этого созданы.

В чем проблема использовать константы? Все это отлично поддерживается
postgrespro.ru/docs/postgrespro/11/plpgsql-declarations

Насчет рефакторинга: если меняется структура какой-то таблицы, то достаточно обновить SQL-запросы только в тех хранимках, где эта таблица используется. Как правило, это не более 10 хранимок. Отсутствие доступа к таблицам вне хранимок заметно упрощает весь процесс.

Модель SQL-NoSQL позволяет вводить множество новых сущностей без изменения структуры — об этом расскажу в отдельной статье

Спасибо за пожелания) Но это слабый аргумент. Когда-то и без PHP обходились, а потом поняли его преимущества. Сейчас новый цикл пошел — поэтому и предлагаю немного пошире взглянуть на решение таких важных задач, как работа с данными.

А зачем тогда нужен PHP ?)

Примерно так (ldLastDate — это переменная типа «date»)

RETURN
(WITH "user_list" AS
 (SELECT
    "user_subscriptions".user_id,
    "user_subscriptions".subscr_date 
  FROM "user_subscriptions"
  WHERE ("user_subscriptions".status = 1) AND
   ("user_subscriptions".subscr_date <= ldLastDate)
 )

SELECT jsonb_agg(jsonb_build_object(
  'userId', "user_list".user_id,
  'userName', "users".user_name
  'subscrdate', "user_list".subscr_date))
FROM "user_list"
LEFT JOIN "users" 
  ON ("users".user_id = "user_list".user_id)
);

Пришлите аналогичный результат на не-SQL языке

Спасибо за комментарий!

Чтобы любой проект не превратился в легаси, его надо регулярно рефакторить (т.е. переписывать довольно значительные куски кода). Проект растет, появляются новые сущности, меняется структура данных, меняются интерфейсы и т.д.

У нас такая процедура делается ежегодно, занимает 2-3 недели.

К примеру, есть два проекта: в одном 1 млн. строк кода, в другом 30 тыс. строк кода. В рамках рефакторинга обычно переписывается 20% кода (по нашей практике).

Вопрос: на какой из проектов потребуется меньше ресурсов?

pgSQL хорошо гармонизирует с SQL.

Главный плюс, на мой взгляд, что в рамках одного SQL-запроса можно сразу сделать множество действий, что часто экономит 90+% ресурсов и времени.

Например, для выполнения какой операции надо сделать 10 действий. Сейчас в PHP делается 10 разных запросов, получаются сырые данные, потом как-то обрабатываются. Альтернатива — все это сделать в одном запросе:

1. Сначала из больших таблиц выбираются данные во временные таблицы (CTEs). Это делается строго один! раз
2. Далее работа идет с временными таблицами: они компактные, сидят в памяти
3. В концовке делаются необходимые обновления и формирование ответа.

Возьмите пример в своем проекте и попробуйте сделать через SQL — сами почувствуете разницу.

Здесь дело привычки, конечно. Единичные проекты требуют терабайтных баз с сотнями тысяч транзакций в секунду, но такие проекты и стоят много ярдов $ ))

Давайте начнем с того, что попробуем представить проект, в котором требуется более 3-х грамотных SQL-разработчиков. Я пока не смог такой представить — помогите в этом вопросе.

SQL-язык тем и хорош, что отлично подходит не только для написания запросов, но и для чтения этих запросов другими программистами. По нашему опыту, ввод грамотного разраба в тему занимает около месяца — затем он пишет качественные хранимки. Чем компактнее и понятнее ваш код, тем проще его и поддерживать, и развивать, и новых людей привлекать

Если микросервисы не лезут в базу, то какие тут могут быть проблемы? Все обновления в базе идут через хранимки, они выполняются внутри базы по транзакционной модели.

Приведите примеры, когда могут возникнуть проблемы целостности

Насчет потери разработчика: код в хранимках получается заметно компактнее, чем в не-SQL языках. SQL собственно для того и создан, чтобы не только писать запросы, но и понимать эти запросы. Вкупе с компактной структурой данных и комментами внутри хранимок войти в курс дела за 1 месяц для грамотного новичка реально — проверили на своем опыте.

Мне сложно представить проект, в котором для разработки хранимок требуется больше 3-х разработчиков, которые отлично знают SQL. Пришлите примеры таких проектов — давайте их обсудим.

Спасибо за вопросы!

1. В базу мигрировала бизнес-логика, связанная с обработкой данных (все, что можно сделать с помощью SQL). Другую логику переносить в базу данных нет смысла. Взаимодействие с внешними сервисами осталось в микросервисах, взаимодействие между базой и микросервисами — через прокси-сервис.

2. Для триггерных событий мы используем воркер на GoLang, который регулярно (раз в N секунд) дергает определенную хранимку в базе. А хранимка уже по нужному расписанию делает расчеты. Событие по дням рождения, к примеру, рассчитывает в ночные часы, когда нагрузка минимальна.

Приветственное письмо при регистрации отправляется сразу после регистрации: хранимка вместе с ответом фронту возвращает инструкцию для прокси-сервиса, что надо вызвать микросервис «emailing», чтобы он отправил письмо с таким-то текстом на такой-то адрес.

3. Используем, конечно. Например, надо отправить несколько миллионов пушей. За один раз это не сделаешь (внешний API не позволит), поэтому формируется в таблице заданий определенный пул, и по N заданий отправляется на обработку.

Также используем очередь на стороне микросервисов: например, после рассылки приходит миллион нотификаций о статусах доставки. Писать их в базе по одному очень накладно. Удобнее объединить в пакеты по 1000 и одним вызовом записать.

До этого ванговали, что через год-два все закончится. Теперь 5 лет) Ставки растут…

Насчет внешних ключей написал в комменте к статье
habr.com/ru/post/515628

Там как раз идет конструктивное обсуждение разных кейсов с хранимками