Как сделать базу данных сайта: схема, API и безопасный доступ

База данных нужна сайту, когда записи должны добавляться, меняться, связываться с пользователями или переживать обновление страницы. Рабочая схема состоит из таблиц, серверного или защищённого API, правил доступа и резервного копирования. Ниже показан минимальный путь для каталога или заявок, а также границы, где простой файл надёжнее базы.

Сначала проверьте, нужна ли сайту база

Не каждая страница выигрывает от базы данных. Статический текст, контакты и небольшой каталог, который меняет один редактор, проще хранить в CMS, JSON-файле или таблице сборки. База оправдана, когда данные вводят разные люди, нужны личные записи, поиск, статусы или связи между сущностями.

• Форма обратной связи может отправлять письмо без собственной базы, если история заявок не нужна на сайте.
• Каталог с редкими обновлениями может жить в CMS или файле.
• Личный кабинет, заказы, комментарии и бронирования требуют постоянного хранилища и правил доступа.
• Секретные данные нельзя хранить в JavaScript, HTML или публичном JSON.
• Если проекту нужна одна полезная функция, сначала ограничьте MVP, как в плане сайта-сервиса.

База данных начинается не с кнопки «Создать проект», а со списка сущностей, действий и ролей. Если нельзя объяснить, кто какую строку читает и меняет, подключать сайт ещё рано.

Карта результата для первой версии

Возьмём безопасный учебный пример: каталог заявок без паролей и платёжных данных. Посетитель отправляет имя, контакт и сообщение, оператор видит заявки в закрытой панели и меняет статус. Это уже требует записи, чтения и обновления, но не вынуждает строить сложную систему.

• Сущность: заявка.
• Поля: идентификатор, имя, контакт, сообщение, статус, время создания.
• Роли: посетитель создаёт запись, оператор читает и меняет статус.
• Публичное действие: только добавление заявки через проверенный обработчик.
• Закрытые действия: список заявок, контактные данные, смена статуса и удаление.
• Проверка: посетитель не может получить чужие строки даже прямым запросом к API.

Если нужна только отправка формы, сравните этот план с более простым вариантом в статье про сайт с формой заявки. База добавляет ответственность: данные надо защищать, очищать, копировать и удалять по правилам проекта.

Как устроена связка сайта и базы данных

У реляционной базы данные лежат в таблицах с одинаковыми наборами колонок для строк. Официальное руководство PostgreSQL описывает таблицы, строки и типы данных, а также отдельно рассматривает запросы, связи и транзакции: учебник PostgreSQL.

Обычная безопасная цепочка выглядит так: браузер отправляет запрос API, сервер проверяет данные и права, затем обращается к базе. PostgreSQL использует клиент-серверную модель, где веб-сервер выступает одним из клиентов базы: архитектура PostgreSQL. Прямой адрес базы и пароль не должны попадать в код страницы.

Браузер -> HTTPS API -> проверка входных данных -> база
База -> результат -> фильтрация ответа -> браузер

По теме: Как сделать сайт мобильным приложением: PWA в 2026

Какой способ подключения выбрать

Есть три практических пути. Выбор зависит не от модного названия сервиса, а от данных, ролей и возможности обслуживать сервер.

1. CMS или конструктор с коллекциями выбирайте для контента, каталога и простых форм, если платформа уже даёт роли и резервное копирование.
2. Управляемый Postgres с готовым API подходит для вайб-кодинга MVP, если вы готовы настроить авторизацию и правила на каждую таблицу.
3. Свой backend и база нужны, когда есть сложная бизнес-логика, интеграции, фоновые задачи или требования к инфраструктуре.

Для сайта с регистрацией база является только одним слоем. Пароли, сессии и восстановление доступа требуют отдельного контура, поэтому используйте план регистрации на сайте, а не добавляйте колонку password в учебную таблицу.

Минимальная схема без лишних полей

Начните с одной таблицы requests. Не храните несколько значений через запятую в одной ячейке и не используйте имя человека как идентификатор. Идентификатор должен быть уникальным, статус должен принимать только заранее разрешённые значения, а время создания должно ставиться системой.

create table requests (
  id bigint generated always as identity primary key,
  name text not null,
  contact text not null,
  message text not null,
  status text not null default 'new',
  created_at timestamptz not null default now()
);

Этот пример показывает структуру, но сам по себе не защищает доступ и не заменяет миграцию. Перед рабочим запуском добавьте ограничение допустимых статусов, лимиты длины строк и правила удаления. Изменения схемы храните как последовательные миграции, чтобы тестовая и рабочая базы не расходились.

Как подключить управляемую базу безопасно

В сервисах с доступом из браузера безопасность строится на ограниченном публичном ключе и правилах для строк. Supabase указывает, что таблицы, доступные через Data API, нужно защищать Row Level Security и выдавать ролям только необходимые права: официальное руководство по RLS.

Публикуемый ключ может находиться во фронтенде только вместе с корректными правилами. Секретный ключ или роль, обходящая RLS, должны оставаться на сервере: руководство Supabase по защите данных. Если сервис предлагает один полный ключ для всех операций, не вставляйте его на страницу, поставьте между сайтом и базой backend.

1. Создайте отдельный тестовый проект и таблицу по минимальной схеме.
2. Включите RLS до подключения формы.
3. Отзовите лишние права и разрешите только нужные операции.
4. Для публичной формы разрешите добавление только через проверяемую политику или серверную функцию.
5. Чтение заявок оставьте авторизованной роли оператора.
6. Проверьте разрешённый и запрещённый сценарий разными пользователями.
7. Только после теста перенесите миграцию и настройки в рабочий проект.

По теме: Как сделать сайт-мессенджер: план MVP с авторизацией и чатом

Как проверить базу до публикации

Проверка «заявка появилась» недостаточна. Нужны положительные и отрицательные тесты. Запишите ожидаемый код ответа, видимые поля и состояние таблицы после каждого шага.

• Корректная заявка создаёт одну строку, повторное нажатие не создаёт дубликат.
• Пустое имя, слишком длинное сообщение и неверный формат контакта отклоняются до записи.
• Неавторизованный запрос списка заявок получает отказ, а не пустую страницу с кодом успеха.
• Оператор видит только нужные поля и может сменить статус.
• Удалённая или изменённая запись отражается после обновления страницы.
• Резервная копия создаётся, а восстановление проверяется на отдельной тестовой базе.
• Логи не содержат пароли, секретные ключи и полные контактные данные.

Диагностика по симптому

Форма пишет «успешно», но строки нет. Проверьте ответ API и серверный журнал. Интерфейс не должен показывать успех до подтверждения записи. Затем проверьте имя таблицы, обязательные поля и права insert.

В браузере ошибка доступа. Не отключайте защиту целиком. Сначала определите роль запроса, затем проверьте выданное право и отдельную политику для нужной операции. Слишком строгая политика безопаснее временной публичной записи и чтения.

Посетитель видит чужие данные. Немедленно закройте endpoint или отзовите публичное чтение. После этого проверьте каждое правило с двумя учётными записями и оцените, какие данные могли быть раскрыты.

Тест работает, рабочий сайт нет. Сравните переменные окружения, адрес API, миграции и правила доступа. Не копируйте рабочий секрет во фронтенд ради быстрой проверки.

По теме: Как создать свой конструктор сайтов: план MVP в 2026

Ограничения и случаи, когда нужен специалист

Учебная схема не подходит для платежей, медицинских сведений, документов, массовой рассылки и сложной многопользовательской системы. Там нужны отдельная модель угроз, требования закона, аудит доступа, шифрование, план восстановления и наблюдение за сбоями. Если потеря или утечка строки причиняет реальный ущерб, привлеките backend-разработчика до запуска.

Для простой публичной таблицы без редактирования база тоже может быть избыточна. Сначала оцените вариант сайта с таблицей: файл или CMS легче проверить и восстановить, если данные обновляет один человек.

Частые вопросы

Можно ли сделать базу данных сайта без программирования?

Да, через CMS, конструктор или управляемую платформу. Но правила доступа, резервное копирование и отрицательные тесты остаются обязательными, даже если код генерирует сервис.

Какую базу выбрать для первого сайта?

Если нужны связанные записи и развитие проекта, обычно удобен управляемый реляционный сервис. Если данные только показываются и редко меняются, начните с CMS или файла.

Можно ли подключить базу прямо из HTML?

Статический HTML не должен содержать полный пароль базы. Допустим защищённый Data API с ограниченным публикуемым ключом и RLS, либо собственный серверный endpoint.

Нужна ли отдельная база для каждого сайта?

Не всегда. Один сервер базы может обслуживать несколько приложений, но разделяйте проекты, роли, схемы и резервные копии так, чтобы ошибка одного сайта не открыла данные другого.