phpPgAdmin — SQL, DDL и DML

ДЛЯ НОВИЧКОВ

Разработчику

После установки и первого входа phpPgAdmin становится визуальным клиентом к PostgreSQL. Всё, что можно сделать в консоли psql или в коде через PDO, здесь доступно через дерево объектов слева, формы и редактор SQL.

Главное отличие от MySQL и phpMyAdmin: в PostgreSQL объекты живут внутри схемы (namespace), а не только внутри базы. Дерево phpPgAdmin отражает иерархию сервер → база → схема → таблица. Команды SQL те же, что на SQL-тренажёре, но синтаксис и модель прав заметно отличаются от MySQL — см. сравнение четырёх СУБД.

Ключевая привычка на старте — различать DDL (структура) и DML (данные). Это те же категории, что в разделе SQL и в статье DDL, DML, DCL, TCL:

Категория	Расшифровка	Что меняет	Примеры
DDL	Data Definition Language	Схему — базы, схемы, таблицы, индексы	CREATE, ALTER, DROP
DML	Data Manipulation Language	Строки внутри таблиц	INSERT, UPDATE, DELETE, SELECT
DCL	Data Control Language	Права ролей	GRANT, REVOKE, CREATE ROLE
TCL	Transaction Control Language	Границы транзакций	BEGIN, COMMIT, ROLLBACK

phpPgAdmin не добавляет новый язык — он отправляет обычный SQL на сервер от имени вошедшей роли PostgreSQL. Видимые базы, схемы и разрешённые операции определяются привилегиями, выданными через GRANT (см. статью 2).

Синтаксис SELECT, JOIN и агрегатов — Оператор SELECT — синтаксис и стиль, Алиасы, JOIN и объединение таблиц, Фильтрация и группировка в SQL. Практикум на схеме магазина — Практикум shop_data.

---

Где выполнять SQL

В интерфейсе есть несколько точек входа в редактор. Они отличаются контекстом — тем, какая база, схема или таблица уже выбрана, и нужно ли писать полное имя schema.table.

Место	Область действия	Как открыть
Вкладка SQL на сервере	Любые запросы к серверу	Верхнее меню после входа
SQL внутри базы	Запросы в контексте БД; search_path включает public	База → SQL
SQL внутри схемы	Объекты схемы без префикса	Схема → SQL
SQL у таблицы	Удобно для SELECT с фильтром по таблице	Таблица → SQL
История (History)	Повтор ранее выполненных запросов	В поддерживаемых версиях

Что умеет редактор

В поле ввода можно:

• выполнить один или несколько запросов подряд (пакетное выполнение; теория bulk/chunk — Пакетная работа с данными);
• просмотреть историю текущего сеанса (в зрелых ветках 5.x);
• получить результат SELECT в виде таблицы с сортировкой по клику на заголовок столбца (с 3.x);
• выполнить EXPLAIN / EXPLAIN ANALYZE для разбора плана запроса — первый шаг к оптимизации PostgreSQL и главам Оптимизация SQL-запросов, Сложные индексы.

Результат SELECT показывается таблицей с постраничной навигацией. После функций, возвращающих SETOF, или пакетного выполнения возможны несколько result set — phpPgAdmin выведет их последовательно.

search_path и полные имена

Если запрос выполняется на уровне базы, PostgreSQL ищет таблицы в схемах из search_path (по умолчанию часто public). На уровне схемы контекст уже сужен. Для надёжности в скриптах и миграциях пишите полное имя: app.users, а не только users.

Пример — проверка соединения

SELECT version();
SELECT current_database(), current_schema(), current_user;

Разбор построчно:

• SELECT version(); — служебный запрос DML-класса (чтение). Возвращает версию сервера PostgreSQL; полезно убедиться, что вы подключены к ожидаемому инстансу (сравните с PostgreSQL — практика).
• current_database() — имя активной базы данных.
• current_schema() — первая схема в search_path, где PostgreSQL ищет объекты без префикса.
• current_user — роль, под которой выполняется запрос (та же, что на странице входа phpPgAdmin).

Оба запроса можно выполнить одним нажатием — phpPgAdmin разделит их по ; и выполнит по порядку.

---

Базы и схемы (DDL)

На уровне сервера вы работаете с каталогом баз данных. Внутри каждой базы — схемы — логические контейнеры для таблиц, представлений, функций и sequences. Схема public создаётся по умолчанию, но в зрелых проектах часто заводят отдельные схемы (app, audit, staging) для изоляции модулей — см. реляционную модель и нормализацию.

Уровень	Аналог в MySQL	Что хранится
База данных	База ≈ схема	Изолированный набор схем и данных
Схема	Нет прямого аналога	Таблицы, индексы, views, functions внутри базы
Таблица	Таблица	Строки данных

Создание базы

Через интерфейс

1. Уровень сервера → Create database ("Создать базу данных").
2. Имя, владелец, кодировка (UTF8 для новых проектов).
3. Подтвердить создание.

Через SQL (DDL)

CREATE DATABASE shop
  ENCODING 'UTF8'
  LC_COLLATE 'ru_RU.UTF-8'
  LC_CTYPE 'ru_RU.UTF-8'
  TEMPLATE template0;

Разбор:

• CREATE DATABASE shop — создаёт пустую базу без прикладных таблиц; внутри появится схема public.
• ENCODING 'UTF8' — кодировка по умолчанию для текстовых данных в этой базе.
• LC_COLLATE / LC_CTYPE — правила сравнения и классификации символов (сортировка, ORDER BY, уникальные индексы). Должны быть согласованы с локалью ОС или контейнера.
• TEMPLATE template0 — чистый шаблон без пользовательских объектов. Нужен, если кодировка или locale отличаются от шаблона по умолчанию (template1).

Тот же DDL в psql или в миграции Laravel/Symfony даст тот же результат — phpPgAdmin лишь отправляет текст на сервер.

Схемы

Схема — namespace внутри базы: полное имя таблицы выглядит как app.users, а не shop.app.users. Несколько схем в одной базе позволяют разделить приложение и служебные объекты без создания отдельных баз.

CREATE SCHEMA app AUTHORIZATION app_owner;
SET search_path TO app, public;

Разбор:

• CREATE SCHEMA app AUTHORIZATION app_owner — создаёт схему app и назначает владельца app_owner (роль с правом CREATE в этой схеме).
• SET search_path TO app, public — PostgreSQL сначала ищет объекты в app, затем в public. Без этого SELECT * FROM users может не найти таблицу, если она не в public.

В phpPgAdmin схемы видны под базой в дереве слева. В зрелых ветках 5.x можно:

• изменить владельца схемы;
• экспортировать схему отдельно от всей базы;
• просмотреть список объектов внутри схемы.

Удаление

DROP DATABASE shop;
DROP SCHEMA app CASCADE;

Разбор:

• DROP DATABASE shop — удаляет базу целиком со всеми схемами и данными. Безвозвратно; перед удалением делайте экспорт.
• DROP SCHEMA app CASCADE — удаляет схему и все зависимые объекты (таблицы, views, functions). CASCADE снимает зависимости автоматически — используйте осознанно, особенно на проде.

DROP на продакшене

На проде DROP DATABASE и DROP SCHEMA CASCADE обычно запрещены для прикладных ролей. Полные права есть у суперпользователя или администратора. Перед DDL на живых данных — резервная копия через pg_dump.

---

Таблицы, индексы, ограничения (DDL)

Таблица — основной объект реляционной модели: именованный набор столбцов с типами и ограничениями. Создание и изменение таблицы меняет метаданные в системном каталоге PostgreSQL (см. Словарь данных и каталоги).

Создание таблицы

Мастер (визуально)

1. Схема → Create table.
2. Имя таблицы, число столбцов.
3. Для каждого столбца задайте:
   • имя — латиница, без пробелов; в PHP-коде то же имя в запросах;
   • тип — integer, bigint, varchar, text, timestamptz, jsonb, uuid и др. (шпаргалка — PostgreSQL — типы);
   • NULL / NOT NULL — допускает ли столбец отсутствие значения;
   • значение по умолчанию — например now() для метки времени;
   • PRIMARY KEY, UNIQUE, CHECK, FOREIGN KEY.
4. В PostgreSQL нет выбора движка таблицы (InnoDB/MyISAM) — хранение определяется access method (по умолчанию heap).

Вкладка SQL или общий редактор:

CREATE TABLE app.users (
  id         BIGSERIAL PRIMARY KEY,
  email      VARCHAR(255) NOT NULL UNIQUE,
  meta       JSONB,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Разбор фрагмента:

Фрагмент	Назначение
app.users	Полное имя: таблица users в схеме app
BIGSERIAL PRIMARY KEY	Автоинкремент через связанную sequence; 64-битный целочисленный ключ
VARCHAR(255) NOT NULL UNIQUE	Строка до 255 символов; NULL запрещён; второй такой email не пройдёт
JSONB	Бинарный JSON — индексируемый, удобен для полуструктурированных атрибутов
TIMESTAMPTZ NOT NULL DEFAULT now()	Метка времени с часовым поясом; при вставке без created_at подставится текущий момент

BIGSERIAL — сокращение для BIGINT + неявного создания sequence. В дереве phpPgAdmin sequence отображается отдельным узлом рядом со схемой (например users_id_seq). Подробнее о sequences — ниже.

Полученный DDL можно скопировать в миграцию фреймворка или в репозиторий — это тот же текст, что показывает phpPgAdmin в разделе структуры таблицы.

Изменение структуры (DDL)

Эволюция схемы в живом проекте почти всегда идёт через ALTER TABLE. В phpPgAdmin каждое действие в форме "Columns" / "Constraints" генерирует соответствующий SQL — удобно учиться, сравнивая кнопку и текст запроса.

Задача	Интерфейс	SQL
Добавить столбец	Columns → Add	ALTER TABLE app.users ADD COLUMN name text;
Изменить тип / ограничение	Alter column	ALTER TABLE ... ALTER COLUMN ... TYPE ...
Индекс	Indexes	CREATE INDEX idx_users_email ON app.users (email);
Внешний ключ	Constraints	ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY ...
Удалить таблицу	Drop	DROP TABLE app.users CASCADE;

phpPgAdmin поддерживает каскадное удаление столбцов и ограничений (с 3.0-beta).

Пример внешнего ключа — связь с другой таблицей в той же схеме:

ALTER TABLE app.orders
  ADD CONSTRAINT fk_orders_user
  FOREIGN KEY (user_id) REFERENCES app.users (id)
  ON DELETE RESTRICT;

Разбор:

• FOREIGN KEY (user_id) REFERENCES app.users (id) — каждый user_id в orders должен существовать в users.
• ON DELETE RESTRICT — нельзя удалить пользователя, пока на него ссылаются заказы. Альтернативы: CASCADE (удалить заказы вместе с пользователем), SET NULL.

Сложные индексы (составные, частичные, GIN для jsonb) — Сложные индексы; для PostgreSQL частичные индексы — мощный инструмент, которого нет в MySQL в том же виде.

Представления, функции, триггеры

На уровне схемы доступны разделы Views, Functions, Triggers (с 3.0 — триггеры, функции с указанием volatility и SETOF). Операции:

• создать и изменить объект через форму или SQL;
• просмотреть исходный код определения в редакторе;
• экспортировать определение в дамп;
• удалить объект (DROP).

Это тот же DDL/DML, что в хранимых процедурах и триггерах, только с подсветкой синтаксиса в браузере. phpPgAdmin не компилирует функции сам — валидирует и передаёт на сервер.

Для сложной логики удобнее хранить определения в миграциях репозитория (Flyway, Liquibase, Laravel migrations), а UI использовать для отладки и быстрых правок на локальной машине.

---

Данные в таблицах (DML)

Когда схема готова, работа сдвигается к строкам — чтение, вставка, обновление, удаление. В терминологии SQL это DML; чтение (SELECT) иногда выделяют в отдельную категорию DQL — см. категории команд.

Просмотр

Вкладка Browse — постраничный вывод строк:

• сортировка по клику на заголовок столбца;
• развёртывание длинных значений (text, jsonb) в отдельном окне;
• экспорт видимой выборки.

За кулисами phpPgAdmin строит SELECT * FROM schema.table LIMIT ... OFFSET ... с учётом сортировки. Для сложных условий переходите на вкладку SQL или пишите запрос с WHERE, JOIN — Оператор SELECT — синтаксис и стиль, Алиасы, JOIN и объединение таблиц.

Вставка

Способ	Когда использовать
Insert (форма)	Одна строка, проверка ограничений вручную
SQL	Массовая вставка, RETURNING, копирование из скрипта

INSERT INTO app.users (email) VALUES ('user@example.com')
RETURNING id;

Разбор:

• INSERT INTO app.users (email) — целевая таблица и список столбцов; id и created_at заполнятся автоматически (BIGSERIAL и DEFAULT now()).
• VALUES ('user@example.com') — одна новая строка. Несколько строк: VALUES (...), (...), (...).
• RETURNING id — идиоматично для PostgreSQL: сервер сразу вернёт сгенерированный id без отдельного SELECT. В MySQL аналог — LAST_INSERT_ID(); в PDO удобно читать $stmt->fetchColumn().

Массовую загрузку из файла удобнее делать через импорт или COPY; для тысяч строк из приложения — подготовленные запросы в PDO.

Изменение

Два равноправных пути:

• Edit на строке в Browse — правка полей в форме; phpPgAdmin сгенерирует UPDATE с WHERE по первичному ключу.
• Явный UPDATE во вкладке SQL — нужен для массовых правок и воспроизводимых скриптов:

UPDATE app.users SET email = 'new@example.com' WHERE id = 1;

Разбор:

• SET email = '...' — новое значение столбца.
• WHERE id = 1 — обязательный фильтр при точечном изменении. UPDATE без WHERE затронет все строки таблицы.

В PostgreSQL такой UPDATE можно обернуть в транзакцию (BEGIN … COMMIT) и откатить при ошибке — см. Транзакции.

Удаление

• Выбор строк в Browse → Delete — эквивалент DELETE с WHERE по ключу.
• Явный SQL:

DELETE FROM app.users WHERE id = 1;

DELETE убирает строки, структура таблицы остаётся. Для полной очистки без удаления определения:

TRUNCATE app.users RESTART IDENTITY;

RESTART IDENTITY сбрасывает связанные sequences — аналог сброса автоинкремента в MySQL.

Browse/Edit и первичный ключ

Редактирование строки в UI требует уникального ключа (PRIMARY KEY или UNIQUE), иначе phpPgAdmin не сможет однозначно построить UPDATE/DELETE. В старых версиях PostgreSQL иногда использовали системный столбец oid — в современных таблицах без WITH OIDS полагаться на него не стоит. Всегда проектируйте явный PK.

Sequences

Sequence — отдельный объект PostgreSQL, выдающий монотонно растущие числа. SERIAL / BIGSERIAL создают sequence автоматически; в PostgreSQL 10+ предпочтительнее GENERATED BY DEFAULT AS IDENTITY, но BIGSERIAL по-прежнему широко встречается в коде и дампах.

SELECT nextval('app.users_id_seq');
ALTER SEQUENCE app.users_id_seq RESTART WITH 100;

Разбор:

• nextval('app.users_id_seq') — получить следующее значение (обычно вызывается неявно при INSERT в столбец BIGSERIAL).
• RESTART WITH 100 — следующий nextval вернёт 100; полезно после импорта данных с фиксированными id.

В интерфейсе phpPgAdmin — отдельный узел Sequences с операциями create/alter. При ручной правке sequence следите, чтобы nextval не выдал id, уже существующий в таблице — иначе нарушится уникальность PK.

---

Роли и права (DCL)

В PostgreSQL роль объединяет понятия пользователя и группы: роль может быть "пользователем для входа" (LOGIN), членом других ролей и владельцем объектов. Это единая модель ролей PG — см. PostgreSQL — практика.

Типичная цепочка выдачи прав только на чтение:

CREATE ROLE app_reader LOGIN PASSWORD 'secret';
GRANT CONNECT ON DATABASE shop TO app_reader;
GRANT USAGE ON SCHEMA app TO app_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA app TO app_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA app
  GRANT SELECT ON TABLES TO app_reader;

Разбор построчно:

• CREATE ROLE app_reader LOGIN PASSWORD 'secret' — роль, под которой можно войти в phpPgAdmin и psql.
• GRANT CONNECT ON DATABASE shop — право подключиться к базе (без этого вход в shop невозможен).
• GRANT USAGE ON SCHEMA app — право "видеть" объекты схемы; без USAGE таблицы недоступны даже при SELECT.
• GRANT SELECT ON ALL TABLES IN SCHEMA app — чтение существующих таблиц.
• ALTER DEFAULT PRIVILEGES ... — права на будущие таблицы, которые создаст владелец схемы.

phpPgAdmin предоставляет формы Grant/Revoke на базы, схемы, таблицы, функции; с 3.0 — массовый revoke нескольким ролям.

Раздел Roles на сервере — аналог "Учётных записей" в phpMyAdmin, но семантика другая:

Аспект	MySQL (phpMyAdmin)	PostgreSQL (phpPgAdmin)
Учётная запись	User в mysql.user	Role с атрибутом LOGIN
Группы	Нет в классическом виде	GRANT role TO role
Права на схему	GRANT ON db.*	USAGE на schema + права на таблицы
Суперпользователь	SUPER	SUPERUSER

Подробнее о дампах ролей и pg_hba.conf — статья 4.

---

Сводка DDL, DML и DCL в phpPgAdmin

Категория	Команды / действия	Где в UI
DDL	CREATE/ALTER/DROP DATABASE, SCHEMA, TABLE, INDEX, VIEW	Мастера + SQL
DML	SELECT, INSERT, UPDATE, DELETE	Browse, Insert, SQL
DCL	GRANT, REVOKE, CREATE ROLE	Privileges, Roles
TCL	BEGIN, COMMIT, ROLLBACK	SQL

Практическая шпаргалка типовых сценариев на SQL — Шпаргалка с типичными задачами по SQL; сравнение синтаксиса четырёх СУБД — Шпаргалка SQL — четыре СУБД на одной схеме.

---

Отличия от phpMyAdmin при тех же задачах

Если вы уже знакомы с phpMyAdmin — SQL, DDL и DML, эта таблица поможет не переносить MySQL-привычки в PostgreSQL буквально:

Задача	MySQL (phpMyAdmin)	PostgreSQL (phpPgAdmin)
Автоинкремент	AUTO_INCREMENT	SERIAL / BIGSERIAL / IDENTITY
Дата и время	DATETIME	TIMESTAMP / TIMESTAMPTZ (рекомендуется с TZ)
Строковые идентификаторы	обратные кавычки `	двойные кавычки " для регистрозависимых имён
Движок таблицы	InnoDB / MyISAM	нет "движков", только access method (heap)
Пользователи	MySQL User accounts	Roles с LOGIN
Вставка с id	LAST_INSERT_ID()	RETURNING id
Namespace	одна база = одна схема	база → несколько схем
Экспорт	mysqldump	pg_dump / pg_dumpall — статья 4

---

Связь с PHP (PDO)

Объекты, которые вы создаёте в phpPgAdmin (база shop, схема app, таблица users, роль app_user), — те же имена, что в строке подключения приложения:

$dsn = 'pgsql:host=127.0.0.1;port=5432;dbname=shop';
$pdo = new PDO($dsn, 'app_user', 'secret', [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]);
$pdo->exec('SET search_path TO app, public');

Соответствие полей:

phpPgAdmin	PHP (PDO)
База shop	dbname=shop в DSN
Роль PostgreSQL	второй аргумент new PDO
Схема app	SET search_path TO app, public после подключения
Таблица app.users, столбец email	INSERT INTO users (email) VALUES (?) — если search_path включает app

Подробнее — работа с БД из PHP, PDO и форма → БД. phpPgAdmin удобен для прототипирования схемы и отладки данных на локальном стеке (XAMPP, Open Server, Docker); в проде миграции чаще ведут через фреймворк, а UI — для экстренной диагностики.

Типичный рабочий цикл:

1. Набросать схему app и таблицы в phpPgAdmin или выполнить CREATE TABLE в SQL.
2. Экспортировать структуру (статья 4) в файл .sql для репозитория.
3. Подключить приложение через PDO с search_path и перенести DML в подготовленные запросы с RETURNING.
4. На проде — миграции и CI; phpPgAdmin только при жёстком ограничении доступа.

---

Следующий шаг

Дампы, роли и FAQ — pg_dump и pg_dumpall, лимиты PHP, extra_float_digits, сравнение с pgAdmin и типичные ошибки расширения pgsql.

EXPLAIN ANALYZE на вкладке SQL — первый шаг к оптимизации 8.11 и главам Оптимизация SQL-запросов, Сложные индексы.

---