Как добавить базу данных в приложение (и не потерять данные потом)

Чтобы добавить базу данных в приложение, выберите управляемую реляционную базу (обычно берут Postgres), храните строку подключения в секретах на сервере, создайте одну таблицу на каждый вид данных, которые хранит приложение, и пусть ваш бэкенд, а не браузер, читает из неё и пишет в неё. Если вы собираете приложение с помощью ИИ-конструктора, обычно достаточно сказать «сохрани это в базу данных», и агент настроит таблицы и код. Ваша задача — ясно описать данные и проверить, что они действительно сохраняются.

В этом гиде: когда нужна база данных, основные варианты, как описать свои данные и ошибки, из-за которых теряются или утекают данные.

Когда приложению нужна база данных

База данных нужна, когда приложению надо запомнить что-то после того, как страницу закрыли, или поделиться данными между людьми. Типичные признаки:

• Посетители что-то отправляют: форму, регистрацию, бронь, заказ
• У пользователей есть аккаунты с сохранённым собственным контентом
• Администратор должен видеть или редактировать то, что создали другие
• Нужны отчёты или подсчёты за период

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

Ваши варианты

Для большинства небольших и средних веб-приложений правильный выбор по умолчанию — реляционная база вроде Postgres. Она хорошо справляется со связями (у клиента много заказов), поддерживает целостность данных и позволяет потом отвечать на вопросы с помощью SQL. Понятное объяснение Postgres — в гиде что такое Postgres.

Опишите данные до начала сборки

Самое полезное, что можно сделать, — записать сущности, которые хранит приложение, и как они связаны. Знать терминологию баз данных не нужно. Для приложения бронирования это может выглядеть так:

• Клиенты: имя, email, телефон
• Услуги: название, длительность, цена
• Брони: какой клиент, какая услуга, время начала, статус (ожидает, подтверждена, отменена)

Это три таблицы. «Какой клиент» и «какая услуга» становятся связями (внешними ключами) между ними. Правильная структура на раннем этапе важнее любого выбора технологии, потому что менять форму данных, в которых уже есть реальные записи, сложнее, чем поменять верстку страницы.

Несколько практических правил:

• Одна таблица на один вид сущности. Не запихивайте заказы в текстовое поле у клиента.
• У каждой строки должны быть ID и время создания. Они понадобятся позже.
• Используйте правильные типы. Даты — как даты, деньги — как целые копейки или десятичное число, а не как текст.
• Помечайте обязательные поля. Пусть базу данных отклоняет плохие данные, а не только форма.

Примеры промптов

Начинайте с одной функции, а не с целой схемы сразу:

Добавь в это приложение базу данных. Создай таблицу bookings с именем клиента, email, услугой, временем начала и статусом (ожидает, подтверждена, отменена; по умолчанию ожидает). Сохраняй заявки из формы бронирования в эту таблицу, показывай сообщение об успехе и добавь страницу для администратора, где бронирования выводятся от новых к старым.

Потом расширьте:

Добавь таблицу services (название, длительность в минутах, цена в копейках). Замени свободное текстовое поле услуги в бронированиях на связь с services и перенеси существующие бронирования, ничего не удаляя.

И ужесточите:

Убедись, что все чтения и записи в базу выполняются на сервере. Браузер никогда не должен получать строку подключения к базе. Проверяй email и время начала на сервере до вставки записи.

Пошагово

1. Составьте список данных как выше: сущности, поля, связи между ними.
2. Создайте базу. В ИИ-конструкторе попросите об этом в чате. В другом месте создайте управляемый экземпляр Postgres и скопируйте строку подключения.
3. Сохраните строку подключения как секрет (переменную окружения на сервере), а не в коде. См. переменные окружения и секреты.
4. Создайте таблицы. Используйте миграции — версионированные скрипты, которые меняют схему, чтобы изменения были повторяемыми и обратимыми.
5. Постройте серверные маршруты, которые создают, читают, обновляют и удаляют строки (CRUD). Браузер вызывает эти маршруты и никогда не обращается к базе напрямую.
6. Подключите интерфейс к этим маршрутам: формы, которые сохраняют, списки, которые загружаются, пустые состояния, когда данных ещё нет.
7. Проверьте сохранение. Отправьте что-нибудь, перезагрузите страницу, откройте в другом браузере. Если данных нет, значит, они не сохранились в базе.
8. Проверьте доступ. Войдите вторым пользователем и убедитесь, что не видите и не меняете данные первого.
9. Опубликуйте и проверьте снова на живом адресе, потому что опубликованное приложение может использовать другое подключение, чем предпросмотр.

Частые ошибки

• Сохранять в браузер и считать, что данные сохранены. localStorage выглядит рабочим, пока кто-то не откроет приложение на другом устройстве. Всегда проверяйте во втором браузере.
• Класть строку подключения во фронтенд-код. Любой может прочитать фронтенд-код. Это даёт доступ ко всей вашей базе.
• Нет проверок доступа. «Покажи мои заказы» должно фильтровать по вошедшему пользователю на сервере, а не в интерфейсе. Это самая частая дыра в безопасности в приложениях, собранных с ИИ; наш чек-лист безопасности её разбирает.
• Деструктивные изменения схемы. Просьба «переименовать таблицу» или «поменять структуру» может удалить её и создать заново. Если есть реальные данные, пишите: «перенеси существующие строки, ничего не удаляй».
• Хранить файлы в базе. Картинки и PDF должны лежать в файловом хранилище, а в таблице — только их адрес или ключ. См. как добавить загрузку файлов.
• Нет резервных копий. До появления клиентов узнайте, как платформа делает бэкапы и как их восстановить.

Чек-лист

• У каждого вида сущностей своя таблица с ID и временем создания
• Обязательные поля и типы проверяются самой базой данных
• Строка подключения хранится только в секретах на сервере
• Все чтения и записи идут через серверные маршруты
• Каждый пользователь может читать и менять только свои строки
• Данные переживают перезагрузку и видны в другом браузере
• Изменения схемы выполняются миграциями и сохраняют существующие строки
• Вы знаете, как работают резервные копии и восстановление
• Живое приложение проверено после публикации

Добавление базы данных в Mythex

В Mythex у каждого проекта может быть своя выделенная база Postgres — и на Free, и на Pro. Обычно отдельная кнопка «подключить» не нужна: попросите в чате («сохраняй email'ы из листа ожидания в базу данных») или введите /database, и параметры подключения будут добавлены в рабочее пространство и в опубликованное приложение. В настройках проекта видно, активна ли база.

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

Подробнее — в разделе База данных и в рецепте Создать CRUD-приложение в документации. Про вход и данные отдельных пользователей читайте как добавить вход в приложение.

Вопросы