Никогда не сталкивался с задачами где нужен PL/pgSQL, соответственно не понимаю зачем нужен. Пообщался со знакомыми бэкендерами - узнал что они тоже на нём ничего не программируют. Используют обычные императивные языки общего назначения: PHP, Node.js, Python. Видимо, для их задач этого тоже хватает.
Хотел бы узнать что можно новичку на нём сделать, чтобы как минимум понять на кой он нужен, а в идеале сделать pet-project, который не стыдно людям показать.
На курсе SQL-разработчик одной известной школы в качестве итогового проекта студенты разрабатывают сервис управленческой отчётности. Мне это кажется очень трудной задачей. Чтобы в браузере отображался дашборд, его надо верстать HTML+CSS, и каким-то макаром прописывать внутреннюю логику. Для меня это звучит как неподъёмная задача, ну а покупать курс, я, ясен пень, не буду.
Если кто-то набросает какой-нибудь PL/pgSQL код в любом фиддле, для иллюстрации что на нем можно делать - буду премного благодарен.
Есть две категории случаев, где следует использовать хранимые процедуры:
1. Сложные запросы, которые нельзя выразить обычным SQL и при этом слишком дорого отправлять более крупный набор данных клиенту, чтобы он сам всё посчитал.
2. У тебя несколько клиентов и тебе нужно гарантировать целостность. Тогда ты всякие валидации из обычного кода переносишь на СУБД.
В обоих случаях клиент=серверное приложение, ибо толстые клиенты сейчас делать моветон.
1. Сложные запросы, которые нельзя выразить обычным SQL
Могли бы вы пояснить это какие например запросы?
2. У тебя несколько клиентов и тебе нужно гарантировать целостность. Тогда ты всякие валидации из обычного кода переносишь на СУБД.
И здесь, приведите, пожалуйста, пример нескольких клиентов для которых нужно гарантировать целостность. И какие там могут быть валидации, которые из обычного кода переносятся на СУБД.
Просто для меня абстрактно, не могу сам подобрать пример.
pavel_the_man, скажите, для чего вам нужны эти примеры?
Ну например делаешь ты банковскую систему и к базе данных с аккаунтами и транзакциями имеет доступ две разные системы, и при добавлении очередной транзакции - тебе нужно проверить, что на обрабатываемый аккаунт не наложены никакие ограничения/запреты - по сути просто сделать один запрос к соседней табличке, но так как приложения два - мы не можем полагаться, что разработчики обоих систем всё корректно реализуют.
Вот тут и возникает хранимая процедура.
Могли бы вы пояснить это какие например запросы?
Например тебе нужно пройтись по всем строкам таблицы и в зависимости от данных в очередной строке - выполнить разные действия. В процедурном стиле это обычный цикл и пара if-ов.
Есть две категории случаев, где следует использовать хранимые процедуры:
PL/pgSQL используется (обычно) для создания хранимых объектов. Их много (ну хорошо, несколько) типов, и процедуры среди них всего лишь в топе, а если вдруг и лидеры, то явно не безоговорочные. Пользовательские функции и триггеры ничуть не менее популярны.
Akina, ну я немного нетипичную терминологию использую и "процедурами" называю всё что на процедурном языке (не на стандартном языке запросов) в субд пишется.
PL/pgSQL, T-SQL и прочие аналогичные языки в первую очередь предназначены для создания систем, в которых интенсивно используется server-side логика. Ибо возможности и инструментарий такого языка кроет (установленные стандартом) возможности SQL как бык овцу...
А всё остальное - это винтики-бантики.
Если кто-то набросает какой-нибудь PL/pgSQL код в любом фиддле, для иллюстрации что на нем можно делать - буду премного благодарен.
Открываешь документацию по Постгрессу, забиваешь в поиск LANGUAGE plpgsql и получаешь кучу ссылок с примерами кодов. А если это будет документация по ПостгрессПро - так ещё и по-русски.
Подскажите, а что вы имеете ввиду под "интенсивной server-side логикой"? Можете ли вы какие-то примеры привести?
Не понимаю чем это отличается от работы бэкендеров, например моих знакомых, о которых я написал в самом начале вопроса.
Знаю проект, на котором трудятся сразу 3 сеньора бэкендера, и всего один фронтендер миддловского уровня. То есть серверная логика очень интенсивная, требует внимания аж сразу 3 квалифицированных бэкендеров, но процедурного расширения SQL там нет и в помине.
pavel_the_man, простейший пример - ни одна учётная запись в принципе не имеет прямого доступа к данным. Только и исключительно через хранимые процедуры. Очень полезно с точки зрения безопасности, кстати.
редко, но бывает такое, что вынуть данные за один SQL запрос выливается в такую конструкцию, что
как не крути эксплайн, но время исполнения неприемлемо и получается, что прогнать пачку более простых в цикле
быстрее.
А дальше у большинства бакенд и база на одном сервере да еще и через сокет. Нет особого смысла
агрегацию данных из бека переносить в бизнес логику базы.
А у кого есть куча серверов, те в микросервисы как то подались. И см выше - сервис и база на одном хосте.
Показать хранимки кому то, тут тоже сложный момент. На рабочем хосте этого не видно совершенно.
Пример сложного запроса.
Поискать на складе автомагазина наличие запчасти с учетом кроссов.
Например CBT40 CTR.
На рисунке ниже только процентов 70 того ,что надо проверить
Олег, А в чем сложность этого запроса? Вроде как просто джойним таблицы, фильтруем в WHERE и смотрим есть ли запчасть или нет. Ну то есть пользуемся просто SQL.
Или это тот самый случай, когда проще в цикле прогнать простые запросы?
А дальше у большинства бакенд и база на одном сервере да еще и через сокет. Нет особого смысла агрегацию данных из бека переносить в бизнес логику базы. А у кого есть куча серверов, те в микросервисы как то подались. И см выше - сервис и база на одном хосте.
.
Подскажите, правильно я понял из этого предложения, что PL/pgSQL (и всё аналогичное) нужно применять тогда, когда базы лежат на разных серверах; но не тогда когда используется микросервисная архитектура?
при поиске запчастей проблема как всегда в исходных данных.
{k1,k2}, ..... {k1,k2}
это фирма, артикул.
Можно их нормализовать к своему виду убрав разнонаписание.
Но что ты сделаешь если Фирма переименовалась ? Синонимы.
В результате и так большой список распухнет еще больше.
Хорошо. Для джоина вы решили их сложить в таблицу.
Число записей в ней представляете ?
Сколько номенклатура автозапчастей ? А их заменяемость ?
на счет второго народ не париться видел код где ЧУДО число записей в таблице делало фетчем всех и подсчета их числа. Видел хранимки от целого Чувашского института где в хранимках нужный результат собирался в курсоре сперва выборкой всех записей, а потом удалялись из них не нужные.
Рукожопов везьде хватает.
PL/pgSQL позволяет сгруппировать блок вычислений и последовательность запросов внутри сервера базы данных, таким образом, мы получаем силу процедурного языка и простоту использования SQL при значительной экономии накладных расходов на клиент-серверное взаимодействие.
Читается как не придется нагружать стек TCP/IP передачей бесполезных данных.
Простой
Простой
Средний
