Как создать таблицу в pgAdmin и не потерять второй фикус
Как создать таблицу в pgAdmin через форму или SQL: выбери базу и схему, задай типы колонок и первичный ключ, добавь строки и проверь каталог комнатных растений.
Денис
Продакт LibraChat
9 мин чтения
В первом наброске каталога я попробовал назначить ключом название растения. Написал «Фикус» и посмотрел на подоконники. Фикусов два. Горшки разные, даты покупки тоже. Прежде чем разбираться, как создать таблицу в pgAdmin, пришлось решить, что именно будет отличать одну запись от другой. Иначе удобная форма лишь закрепила бы неудачную идею.
Я сделал короткую шпаргалку: от выбора базы до чтения сохранённых колонок. Её можно пройти через интерфейс или через SQL. Достаточно одного маршрута. Второй нужен, чтобы увидеть ту же конструкцию с другой стороны, а не создать её ещё раз.
Как создать таблицу в pgAdmin: проверь адрес будущего объекта
Сначала разделю вещи, которые новичку видятся одной программой. PostgreSQL хранит данные и выполняет команды. pgAdmin позволяет подключаться к нему и управлять объектами. Значок pgAdmin на рабочем столе ещё не означает, что сервер работает и тебе доступна база.
Если подключение не настроено, в дереве Servers используй Register → Server. Здесь задают параметры уже существующего сервера; регистрация не устанавливает новый PostgreSQL. После определения подключения выбери Connect to Server. Адрес, имя пользователя и пароль берутся у владельца сервера либо из твоей локальной установки.
Дальше нужен отдельный выбор базы. В раскрытом сервере найди Databases и свою учебную базу. Если её ещё нет и у твоей роли есть право создавать базы, выбери Create → Database, задай имя `plants_lab` и сохрани. На общем сервере проще сразу уточнить, где разрешены упражнения: право входа само по себе не даёт права создавать базы.
Внутри базы открой Schemas → public → Tables. `public` здесь имя схемы, а не базы и не сервера. Полное имя нашей таблицы — `public.houseplants`. Обычная новая база содержит схему public, но в настроенной администратором среде набор схем и права могут отличаться.
Я записываю себе адрес в одну строку: сервер → база plants_lab → схема public → таблица houseplants. Если позже объект не находится, возвращаюсь к этому адресу. Искать пропавший горшок по всем комнатам было бы примерно столь же разумно, как повторять создание без проверки подключения.
Карточка таблицы: идентификатор принадлежит горшку
Кнопки пока подождут. В моём каталоге строка означает отдельное растение, а не вид растений. Поэтому названия могут повторяться. Для различения экземпляров я отвёл поле `plant_id`; имя растения осталось обычным текстом.
Колонка · Тип · Ограничение · Зачем нужна
plant_id — integer — PRIMARY KEY — Номер конкретного экземпляра
plant_name — text — NOT NULL — Название растения
room — text — Необязательная — Где находится горшок
acquired_on — date — Необязательная — Когда появился
Тут четыре поля. `integer` хранит целое число, `text` — строку, `date` — календарную дату. Последнее я выделил отдельно: если написать «был куплен весной» в поле комнаты, искать покупки за период станет неудобно. Неизвестную дату можно пока не задавать.
Первичный ключ требует уникального значения и не допускает NULL. В нашем варианте это номер горшка. Назначить ключом `plant_name` означало бы запретить одинаковые названия, хотя два фикуса в разных комнатах вполне уживаются. Ошибка была в правиле учёта.
У `plant_id` нет автоматической нумерации. Номер мы задаём сами. Обозначение PRIMARY KEY не превращает integer в счётчик: генерация значений настраивается отдельно. Мне нравится начинать именно с этого варианта, потому что видно каждое принятое решение.
Для названия стоит NOT NULL. Оно запрещает отсутствующее значение, но не пустую текстовую строку. Если позднее понадобится отвергать пустые названия, добавь соответствующее условие. Сейчас важно не ожидать от одного ограничения поведения другого.
Как создать таблицу в pgAdmin через форму Table
Этот маршрут выбирай, если тебе удобнее сопоставлять карточку с полями окна. Подписи ниже соответствуют документации pgAdmin 4; в конкретной версии компоновка может отличаться.
В выбранной схеме нажми правой кнопкой на Tables, затем Create → Table.
На General введи `houseplants` в Name, проверь Schema: public.
На Columns кнопкой + добавь четыре колонки из карточки. Для каждой укажи Name и Data type.
У `plant_id` включи Primary key?, у `plant_name` — Not NULL?. Две оставшиеся колонки разрешают отсутствие значения.
Перед Save открой вкладку
Я бы задержался на пятом пункте. Не нужно сразу разбирать каждую служебную строку. Найди четыре имени колонок, сравни типы и проверь, какой столбец стал ключом. Окно выглядит правильно не потому, что все вкладки посещены, а потому, что получилось задуманное определение.
Ключ можно описывать и через раздел Constraints. Для этого упражнения достаточно переключателя у `plant_id`: дублировать то же правило другим способом не требуется. После сохранения обнови узел Tables, если дерево не изменилось сразу.
Наличие имени в списке ещё не рассказывает о качестве структуры. Открой свойства таблицы, посмотри Columns и Constraints. Именно там надо искать ответ на вопрос о втором фикусе, а не в количестве зелёных сообщений.
SQL-маршрут: та же таблица одним определением
Если ты уже создал таблицу через форму, этот раздел можно прочитать без выполнения CREATE. Для самостоятельного SQL-маршрута открой Query Tool в контексте нужной базы или через меню Tools.
Сначала проверь, к какой базе относится окно. Можно выполнить отдельный короткий запрос:
```sql
SELECT current_database();
```
Имя должно соответствовать базе, которую ты выбрал для занятия. Указание `public` в команде ниже не переключает базу: оно выбирает схему внутри текущего подключения. Эту разницу удобно усвоить до первой таблицы.
Затем вставь определение:
```sql
CREATE TABLE public.houseplants (
plant_id integer PRIMARY KEY,
plant_name text NOT NULL,
room text,
acquired_on date
);
```
Выдели целиком этот фрагмент и нажми Execute script. В режиме выполнения скрипта без выделения сервер получает всё содержимое редактора. Поэтому я держу первую команду отдельно: так легче понять, что именно сейчас отправляется на выполнение.
Читай Messages. Если Auto commit выключен, успешную транзакцию нужно завершить через Commit. Сохранение SQL в файл и фиксация изменений в базе — разные действия. Файл хранит текст команды; Commit завершает транзакцию на сервере.
Когда имя уже занято, остановись и открой существующий объект. Удалять таблицу ради повторения упражнения не нужно. Для независимой попытки заранее выбери другое свободное имя и используй его последовательно во всех запросах.
Я не прячу повтор создания за IF NOT EXISTS. Такая оговорка может пропустить существующий объект, но не доказывает, что у него нужные колонки. В первом упражнении полезнее заметить эту развилку, чем получить спокойное сообщение ценой непонятного результата.
Два фикуса: добавление записей без путаницы
Теперь добавим пример данных. Команда ниже предназначена для однократного выполнения в пустой таблице, созданной одним из двух маршрутов. Номера 1001 и 1002 различаются намеренно, названия совпадают.
```sql
INSERT INTO public.houseplants
(plant_id, plant_name, room, acquired_on)
VALUES
(1001, 'Фикус', 'Кухня', DATE '2026-04-12'),
(1002, 'Фикус', 'Гостиная', NULL);
```
Во второй записи дата неизвестна. NULL записан без кавычек: это отсутствие значения, а не слово для хранения в колонке. В первой записи дата задана явно. Названия комнат заключены в одинарные кавычки, как текстовые значения.
Вставка не создаёт таблицу заново. Она добавляет строки в существующую структуру. Чтобы посмотреть их, выполни отдельно:
```sql
SELECT plant_id, plant_name, room, acquired_on
FROM public.houseplants
ORDER BY plant_id;
```
После успешной однократной вставки в пустую таблицу ожидаются две записи. Порядок задан через ORDER BY: нельзя считать порядок добавления постоянным порядком чтения. На этом маленьком наборе разницу легко не заметить, но лучше сразу записывать своё намерение явно.
Если выполнить этот INSERT 2 раза с теми же номерами, повтор нарушит ключ. Это не запрет второго фикуса, а запрет второй записи с тем же идентификатором. Я проверил эту логику ещё на бумажном плане: два разных названия с одним номером тоже конфликтуют. Название и номер отвечают на разные вопросы.
Если ошибка прервала ручную транзакцию, сначала заверши её откатом через Rollback, а затем исправляй запрос. Не продолжай накапливать команды поверх незавершённой неудачной попытки.
Проверка колонок: что действительно сохранено
Мне хочется закончить упражнение сверкой структуры, а не очередным нажатием кнопки. Вот запрос к сведениям о колонках текущей базы:
```sql
SELECT column_name, data_type, is_nullable
FROM information_schema.columns
WHERE table_schema = 'public'
AND table_name = 'houseplants'
ORDER BY ordinal_position;
```
Сопоставь выдачу с карточкой. Должны присутствовать четыре названные колонки нужных типов. `is_nullable` показывает, допускается ли NULL; проверка самого первичного ключа требует отдельно посмотреть Constraints в свойствах объекта. Этот запрос ключи не перечисляет.
Когда сверка не сходится, я разбираю её по признакам:
Нет строк с метаданными: проверь базу подключения, имя схемы и доступ к объекту.
Имена или типы отличаются: открой свойства и выясни, тот ли экземпляр таблицы выбран.
Название допускает NULL: сравни ограничение с карточкой; одного совпадения типа text недостаточно.
Для меня это надёжнее догадки «наверное, Save не сработал»: у такой догадки слишком много возможных причин. А здесь следующий шаг зависит от того, какое именно несоответствие ты увидел.
Своя таблица: попроси объяснить правила до запуска
Когда исходные записи ещё разбросаны по заметкам, пригодится пример переноса текста в строки и колонки. В PostgreSQL к такой организации добавляются правила, которые сервер применяет при изменении данных. Их полезно уметь объяснить до расширения каталога.
Помоги спроектировать таблицу PostgreSQL для комнатных растений. Одна строка означает один конкретный горшок. Названия могут повторяться, дата покупки иногда неизвестна. Номер задаю вручную. Объясни выбор типов и первичного ключа, затем предложи CREATE TABLE и два примера INSERT. Отдельно объясни, какие ошибки в данных обнаруживают выбранные ограничения, а какие не обнаруживают.
Здесь полезен разговор о решениях, а не передача доступа к серверу: параметры подключения для такого разбора не нужны. Полученный SQL сначала прочитай, сравни с задачей и выполняй в своей учебной базе. Чат не заменяет проверку выбранного подключения в pgAdmin.
Перед регулярными занятиями можно посмотреть доступные условия работы. А первое маленькое задание у меня другое: объясни, почему двум фикусам разрешено одинаковое название, но нельзя выдать одинаковый plant_id. Если ответ понятен, ты уже проектируешь таблицу. Кнопка Create лишь оформляет принятое решение.
