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