PgConf.Russia 2017

Я очень люблю сложные предметные области, строгую типизацию в приложении и 3НФ, но очень не люблю ORM. Поэтому мне приходится активно использовать хранение сериализованных структур в json-полях (даже до появления типа json). В докладе расскажу о некоторых особенностях работы с хранением сложных объектов внутри полей СУБД, расскажу где и как подстелить себе соломку и какие проблемы могут возникнуть.

ВИДЕО

В данный момент в PostgreSQL для исполнения SQL-запросов применяется интерпретатор, реализующий модель итераторов (Volcano-модель). В то же время можно добиться существенного ускорения, выполняя динамическую компиляцию запроса «на лету». В этом случае можно генерировать код, специализированный для конкретного SQL-запроса, а также применять компиляторные оптимизации, учитывая, что во время выполнения уже известна структура используемых таблиц и типы данных. Такой подход особенно актуален для сложных запросов, скорость выполнения которых ограничена производительностью процессора.

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

Зачастую по требованию клиента или даже закона необходимо документировать специфику производства продукта в целом и его частей. Этот доклад посвящен теме автоматической генерации и хранения соответствующей административной информации. К административной информации относятся такие данные как номер поставки, артикул, серийный номер, дата изготовления. Такие данные часто обмениваются с ERP-системами.

Разработку таких приложений можно значительно упростить, если использовать NoSQL-функциональность PostgreSQL, особенно json и jsonb.