Базы данных для вайбкодеров

Слово «база данных» звучит так, будто для него нужен диплом. Нет. База данных — это набор списков, где у каждого элемента одинаковые подписанные ячейки. Если ты когда-нибудь делал таблицу в экселе — ты её уже построил, просто не называл так.

Но вот почему это стоит десяти минут внимания: модель данных — это единственная часть приложения, которую ИИ с трудом чинит потом. Экраны менять легко. Структуру данных, когда приложение уже полно реальных данных, менять больно. Сделать её примерно правильно в начале — значит избежать худшего вида переделок.

Таблица — это подписанный список

Представь одну вкладку таблицы. Столбцы — это подписи; каждая строка — один элемент.

Таблица users:

| id | email | name | created_at | | -- | ----- | ---- | ---------- | | 1 | ann@… | Аня | 2026-05-01 | | 2 | bo@… | Боря | 2026-05-02 |

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

Шаг первый: выпиши существительные

Вернись к спеке и обведи существительные — вещи, с которыми работает приложение. У блога есть посты и комментарии. У магазина — товары и заказы. У трекера привычек — привычки и отметки.

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

Шаг второй: дай каждой вещи ячейки

Для каждой таблицы перечисли, что нужно помнить об одном элементе. У post:

• заголовок (текст)
• тело (текст)
• когда опубликован (дата)
• черновик ли это (да/нет)

Не залипай на типах. Текст, число, да/нет и дата покрывают почти всё на старте. Точные типы выберет ИИ — твоя задача знать, какие факты ты хранишь.

Шаг третий: соедини таблицы

Это единственная по-настоящему новая идея, и она простая. Когда одна вещь принадлежит другой, ты связываешь их через id.

Комментарий принадлежит посту. Поэтому у таблицы comments есть столбец post_id, хранящий id своего поста:

| id | post_id | text | | -- | ------- | ---- | | 1 | 42 | Класс! | | 2 | 42 | Согласен |

Оба комментария указывают на пост 42. Это связь. «Комментарий принадлежит посту» и «у поста много комментариев» — одна и та же связь с двух концов. Девяносто процентов данных в приложении — это просто вещи, указывающие на другие вещи вот так.

Два вопроса, ловящие большинство ошибок

Прежде чем строить на модели данных, проверь её на здравость:

1. «Если я это удалю, что должно случиться со связанными вещами?» Удаляешь пост — должны ли исчезнуть его комментарии? Обычно да. Удаляешь пользователя — а его заказы? Может, ты их оставишь. Решай осознанно.
2. «Не храню ли я один факт в двух местах?» Если адрес клиента лежит и в таблице users, и в каждой строке orders, однажды ты обновишь одно и забудешь другое. Храни каждый факт один раз и ссылайся на него.

Эти два вопроса предотвращают самые грязные и трудноисправимые проблемы с данными.

Пусть ИИ спроектирует — потом допроси его

Тебе не нужно рисовать это в одиночку. Опиши существительные и попроси:

«Спроектируй таблицы базы данных для этого. Покажи каждую таблицу, её столбцы и как они связаны. Объясни, почему ты разбил именно так».

Потом возражай. Спроси «почему это отдельная таблица?» и «что будет, когда я удалю пользователя?». Первый черновик ИИ обычно нормальный, но понимание, почему он такой формы, и есть то, что потом позволит тебе уверенно его менять.

Почему это фундамент

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

Потрать эти десять минут. Назови существительные, дай им ячейки, нарисуй связи. Это самая негламурная часть стройки — и та, что тихо решает, будет ли остальное лёгким или мучительным.