PostgreSQL ACL Server
Уровни доступа к базам данных — постоянный спор между DBA и разработчиками: Разработчики хотят быть SUPERUSER всегда и везде, DBA не хотят разгребать проблемы которые дают эти привилегии в неумелых руках.
Уровни доступа к базам данных — постоянный спор между DBA и разработчиками: Разработчики хотят быть SUPERUSER всегда и везде, DBA не хотят разгребать проблемы которые дают эти привилегии в неумелых руках.
В предыдущей статье мы рассматривали вопросы подключения и глобальных привилегий пользователей сервера PostgreSQL. Будем считать что головную боль админов в виде pg_hba.conf мы прошли, переходим к следующей.
DBA против Разработчиков, DML против DDL. Сразу хочу сказать, что мое мнение: привилегии DDL разработчику не нужны, несмотря на то, что я сам разработчик.
Недавно попросили поднять копию одного проекта для тестов, ну и соответственно потянуть базу данных как есть из боя (pg_basebackup). Выяснилось, что физический размер базы составил 505 GB, что само по себе слегка удивило, не то, чтобы данных там было мало. Много, но не настолько.
Вот проснулись вы как-то утром и решили начать новую жизнь вместе с базой данных PostgreSQL оставив другие за бортом. Но с чего начать? Как «подкатить» и не быть отвергнутым? А ведь вы уже не молоды и «с прицепом»: с данными, нагрузкой и бизнес-логикой.
Так как в данный момент тема миграций в тренде, не могу пройти мимо и не поделится своим опытом подобных мероприятий. Данная задача не самая простая, так как требует подмены одной из фундаментальных технологий проекта — хранилище данных.
При работе с триггерами, особенно в случаях, когда на уровне триггеров производятся каскадные или перекрестные обновления, возникает потребность отключать или производить определенные действия в триггерах прямо на уровне запроса.
Практически каждый из нас сталкивался с проблемой, что нужно добавить дополнительный индекс в таблицу на боевом проекте. При этом объем таблицы очень большой и индекс будет создаваться очень долго, а проект останавливать нельзя.
Рассматриваем простые правила создания и использования составных индексов, немного изучаем в теорию.
Одним из методов хранения древовидных структур является Nested Sets (Вложенные множества).
Прежде всего посмотрим как выглядят деревья Nested Sets, как они организованы и в чем удобство их использования.
Как удобно делать выборки из деревьев типа Nested Sets, и как не удобно им управлять. Как удобно управлять деревьями типа id->parent_id, но как не удобно и накладно использовать рекурсии при выборках.
ltree является дополнением PostgreSQL и входит в пакет contrib, поэтому изначально оно не включено в стандартный пакет для *nix систем
Поддержка — это когда у нас возникает техническая
проблема с существующей системой,
и вам необходимо некоторое руководство