Начнем мы с контейнера верхнего уровня – виртуальной машины (ВМ). Внутри ВМ могут быть установлены разные версии PostgreSQL и на каждой версии может быть развернут 1 или более кластеров PostgreSQL. Я не ошибся – 1 инстанс СУБД PostgreSQL называется кластером в их терминологии.
Далее внутри инстанса у нас существуют 3 базы данных по умолчанию:
postgres – используется:
● первая база данных для регулярной работы
● создаётся по умолчанию
● хорошая практика – также не использовать
● но и не удалять – иногда нужна для различных утилит
template0 – используется:
● для восстановления из резервной копии
● по умолчанию даже нет прав на connect
● не рекомендовано вносить изменения – лучше всего не создавать в ней никаких объектов
template1 – используется:
● как шаблон для создания новых баз данных
● в нём имеет смысл делать некие действия, которые не хочется делать каждый раз при создании новых баз данных – создать хранимые функции/процедуры, создать справочники, включить расширения и т.п.
Конечно мы можем и сами создавать как шаблоны, так и базы данных.
Далее внутри БД у нас есть еще логическое разделение на схемы данных – schema. По умолчанию используется схема public – не самый рекомендованный вариант. Лучше создавать свою именованную схему. По умолчанию объекты (таблицы и др) в схеме видят другие объекты только этой же схемы, что очень удобно для логического разбиения на области видимости.
Внутри схемы уже непосредственно создаются отношения (relation). Одной схеме может принадлежать от 0 и более отношений. Соответственно, каждое отношение принадлежит своей схеме и своей базе данных.
Давайте посмотрим, какие виды отношений (relkind) у нас есть:
● r = ordinary table – обычная таблица – используется для хранения данных
● i = index – индекс – ускоряем поиск данных
● S = sequence – последовательность – генерируем автоматически нумерацию строк
● v = view – представление – грубо говоря сохраненный заранее вид запроса к таблицам
● m = materialized view – материализованное представление – кроме сохраненного текста запроса, также хранит и сами данные
● c = composite type – композитный тип – раширяем стандартный набор типов данных
● t = TOAST table – для хранения слишком больших строк
● f = foreign table – внешние таблицы – подключаем другой инстанс PostgreSQL или другой СУБД
Если представить визуально схему логического устройства PostgreSQL, то она будет выглядеть следующим образом:
Давайте посмотрим на практике.
Подключимся к созданному на предыдущем этапе кластеру и посмотрим список БД используя команду psql:
\l
Создадим свою БД и подключимся к ней:
CREATE DATABASE aeugene;
\c aeugene;
Теперь создадим таблицу и добавим пару записей:
CREATE TABLE test (i serial, t text);
INSERT INTO test(t) VALUES (‘Аристов’),(‘Евгений’);
SELECT * FROM test;
Видим, что автоматический счетчик строк (имя поля i, тип – счетчик с автоматическим увеличением) работает на отлично и обе строки у нас успешно сохранились внутри таблицы test в схеме public (а именно в ней мы по умолчанию и работаем) в БД aeugene.
Какие еще есть возможности по управлению схемой данных для хранения и управления БД мы рассмотрим в следующей статье.
Добавить комментарий