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

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

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

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

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

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

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

Что должна уметь база заявок

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

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

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

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

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

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

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

По теме: Как сделать социальный сайт: профили, лента и приватность

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

Для контента подойдёт CMS, для MVP с готовым API можно выбрать управляемый Postgres, а при сложной логике нужен свой backend. Учитывайте данные, роли и возможность обслуживать сервер.

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

Для сайта с регистрацией одной базы недостаточно: пароли, сессии и восстановление доступа требуют отдельного контура. Используйте план регистрации на сайте. Колонку password в учебную таблицу не добавляйте.

Где разместить базу и как оплатить её из России

Для учебного проекта без карты подойдут бесплатные планы Supabase или Firebase. Если нужна оплата российской картой или через СБП, смотрите на Timeweb Cloud и Yandex Cloud; у них же можно держать бота круглосуточно с оплатой в рублях.

• Supabase подходит для учебного проекта на Postgres: бесплатный план не требует карты, даёт 500 МБ базы на проект и 2 активных проекта, но ставит проект на паузу после недели без активности. Pro стоит от $25 в месяц, а платные тарифы оплачиваются только картой, так что из России для перехода на Pro понадобится карта зарубежного банка. Чтобы аккаунт не попал под проверку, не меняйте страну в профиле туда-сюда и платите картой той страны, что указана в данных плательщика.
• Firebase от Google даёт бесплатный план Spark без способа оплаты: у Cloud Firestore 1 GiB данных, 50 тыс. чтений и 20 тыс. записей в день. Firestore хранит документы и не использует PostgreSQL, поэтому SQL-схему из этой статьи туда напрямую не перенести.
• Timeweb Cloud предлагает управляемые PostgreSQL, MySQL, MongoDB и другие базы в Москве, Санкт-Петербурге и Нидерландах. Цену конфигурации считает калькулятор на странице; отдельно указаны автоматические резервные копии по 6 ₽ в месяц за 1 ГБ и публичный IP за 200 ₽ в месяц. Оплатить можно картой или через СБП, способы перечислены в справке Timeweb Cloud.
• Yandex Cloud Managed Service for PostgreSQL берёт плату по часам за vCPU и RAM хостов, а также за хранилище; резервные копии не тарифицируются, пока их объём не превышает суммарный объём хранилищ хостов кластера. В бесплатные лимиты Yandex Cloud этот сервис не входит. Физлица, резиденты РФ, платят в рублях картой российского банка или через СБП, подходят карты Мир, Visa и MasterCard.

По теме: Как сделать динамический сайт: CMS, база данных или ИИ-сервис

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

Начните с одной таблицы 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' check (status in ('new', 'in_work', 'done')),
  created_at timestamptz not null default now()
);

Ограничение check пропустит в колонку status только значения new, in_work и done. Связь между таблицами задаёт внешний ключ: например, заметки оператора ссылаются на заявку через request_id, и PostgreSQL не даст сохранить заметку к несуществующей заявке. Оба вида ограничений описаны в документации PostgreSQL.

create table request_notes (
  id bigint generated always as identity primary key,
  request_id bigint not null references requests (id),
  note text not null,
  created_at timestamptz not null default now()
);

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

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

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

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

С 30 мая 2026 года Supabase постепенно вводит для новых проектов явные права на новые таблицы в схеме public: без grant они не открываются через Data API. На 30 октября 2026 года назначено применение настройки ко всем существующим проектам; уже созданные таблицы сохраняют свои права. Изменение касается Data API, включая обращения через supabase-js; прямое подключение с сервера через строку подключения, psql или ORM оно не затрагивает. grant определяет доступ роли к таблице, а RLS определяет доступные ей строки. Правила RLS продолжают работать как раньше.

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

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

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

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

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

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

Для резервной копии PostgreSQL выполните pg_dump dbname > dumpfile, а для пробного восстановления используйте psql dbname < dumpfile в отдельной пустой базе; в первой команде замените dbname именем исходной базы, во второй именем тестовой, а dumpfile именем файла копии.

Что делать, если форма не сохраняет заявку или API не пускает

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

В браузере ошибка доступа. Код 42501 с сообщением «permission denied for table …» указывает на отсутствие нужного права на таблицу; API подсказывает, какой GRANT выполнить. Право на таблицу и RLS проверяются отдельно. Сначала определите роль запроса, затем проверьте право и политику для нужной операции. Не отключайте защиту целиком: слишком строгая политика безопаснее временной публичной записи и чтения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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