Серверное программирование в PostgreSQL/

Запись занятия доступна как в ютуб версии, так и на рутуб канале и VK Видео.

Презентация и исходники доступны по ссылке.

Серверное программирование

Зачем нужно:

считать данные из базы
изменить данные
удалить
может получить доступ к файловой системе
может получить доступ к сети, в т.ч. в интернету
разграничить доступ и возможность изменения/удаления данных разработчиками софта для этой БД

Ключевые преимущества

1. Повышение производительности

Снижение сетевого трафика: Вместо пересылки тысяч строк SQL-кода и данных между клиентом и сервером отправляется лишь вызов одной функции. Это значительно уменьшает задержки (latency).
Предварительная компиляция и кэширование: Хранимые процедуры компилируются и оптимизируются один раз при создании, а их планы выполнения кэшируются в памяти, что ускоряет последующие вызовы.
Выполнение вблизи данных (Data Locality): Логика выполняется прямо на том же сервере, где находятся данные, что исключает накладные расходы на передачу и преобразование данных.

2. Централизация бизнес-логики и обеспечение целостности данных

«Единственный источник истины»: Критическая бизнес-логика инкапсулируется внутри БД. Это гарантирует, что все приложения (веб, мобильные, десктопные) будут использовать одни и те же правильные алгоритмы, а не дублировать их у себя.
Согласованность данных: Триггеры автоматически проверяют и поддерживают сложные ограничения целостности, которые невозможно выразить через CHECK или FOREIGN KEY.
Безопасность: Можно предоставлять приложениям права на выполнение процедур, но не на прямые операции INSERT/UPDATE/DELETE к таблицам,скрывая реальную структуру данных.

3. Упрощение и безопасность

Упрощение клиентского кода: Клиентское приложение становится проще и «тупее». Оно просто вызывает CalculateBonus (employee_id), вместо того чтобы реализовывать сложную логику на Java/C#/python.
Защита от SQL-инъекций: Поскольку параметры передаются в предварительно скомпилированные процедуры, это самый надежный способ защиты от инъекций.
Контроль доступа: Администратор может дать права на выполнение процедуры, но не на изменение данных в таблицах напрямую.

4. Обслуживание и управляемость

Легкость модификации: Чтобы изменить бизнес-правило, нужно обновить код всего в одном месте — на сервере БД — а не переписывать все клиентские приложения.
Версионность и документирование: Логика в БД может управляться системами контроля версий (Git) так же, как и любой другой код.

5. Пакетная обработка и сложные операции

Эффективность сложных операций: Операции, требующие множества запросов и промежуточной логики (например, ETL-процессы, сложные отчеты), выполняются максимально эффективно внутри сервера.
Транзакционность: Вся логика внутри процедуры выполняется в рамках одной транзакции, что обеспечивает атомарность (все или ничего).

Типичные сценарии применения

Недостатки

Сложность отладки: Отладка хранимых процедур может быть сложнее, чем клиентского кода.
Привязка к вендору: SQL-диалекты и особенности procedural language (PL/pgSQL, T-SQL, PL/SQL) переносятся между СУБД (PostgreSQL, Oracle, MS SQL) с большим трудом.
Масштабирование: Слишком сложная логика на сервере БД может стать «бутылочным горлышком». Иногда правильнее вынести логику в отдельный микросервис.
Версионность: Требуются дисциплина и процессы для управления версиями кода БД (миграции, например, с помощью Flyway или Liquibase).

Стенд

Комментарии