# Файл, таблица или база: где держать данные своего инструмента

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

URL: https://posts.danashkin.ru/guides/fayl-tablica-ili-baza
Обновлено: 2026-09-07

---

## Коротко

**Главное**

- Где держать данные твоего инструмента, решают три вопроса: кто в них пишет, сколько будет записей и что случится, если они пропадут.
- Пока пишешь только ты и записей сотни, обычных файлов достаточно. Это не временное решение, а нормальное для целого класса задач.
- Таблица появляется, когда данные нужно смотреть и править человеку, а не только программе. База - когда пишут несколько людей одновременно.
- Главная опасность не в выборе, а в незнании: код откатывается назад одной командой, а введённые данные не откатываются никогда.
- Перед любой перестройкой хранилища задаётся один вопрос агенту: что будет с уже введёнными данными. Он экономит вечер работы.

## Что на самом деле определяет выбор хранилища?

**Главное**

Не сложность проекта и не желание сделать по-взрослому, а три вещи: количество пишущих, количество записей и цена потери. Всё остальное - следствие этих трёх ответов.

Разберём по порядку, потому что вопрос «а нужна ли мне база данных» задают почти на каждом обучении, и почти всегда до того, как понятно, что вообще хранится.

**Кто пишет.** Если данные вносишь только ты и только с одного компьютера, задача элементарная. Как только пишут двое одновременно, появляется класс проблем, который сам собой не решается.

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

**Что будет при потере.** Тут вопрос не технический. Пропали заметки за неделю - неприятно. Пропали заявки клиентов за месяц - это уже другой разговор с другими последствиями.

Аналогия из офиса. Записать телефон на стикере нормально, вести бухгалтерию на стикерах - нет. Разница не в сложности записи, а в количестве людей, объёме и цене потери.

Термины, которые встретятся по дороге, я собрал в отдельном [словаре вайбкодинга](/guides/slovar-vibecodinga-bez-zhargona).

## Уровень первый: обычные файлы

**Главное**

Текстовые файлы в папке проекта. Подходят, когда пишешь только ты, записей немного и структура простая. Читаются глазами, редактируются руками, копируются вместе с проектом.

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

Что хорошо ложится в файлы:

- **Настройки и правила.** Как обрабатывать, что игнорировать, какие шаблоны использовать.
- **Тексты.** Описания, инструкции, заготовки писем и документов.
- **Справочники, которые редко меняются.** Список категорий, перечень услуг, шаблоны договоров.
- **Результаты работы.** Готовые сводки, отчёты, выгрузки.

Что плохо: всё, что меняется много раз в день, и всё, во что пишут несколько человек.

**Незаметное преимущество файлов**

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

## Уровень второй: таблица

**Главное**

Обычная электронная таблица как хранилище. Подходит, когда данные должен видеть и править человек, а записей от сотен до нескольких тысяч. Главное условие - плоская структура без объединённых ячеек.

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

Когда таблица - правильный ответ:

1. **Данные ведут люди.** Менеджер вносит заявки руками, а инструмент их читает.
2. **Нужен человеческий просмотр.** Открыть, отфильтровать, поправить опечатку без разработчика.
3. **Данные и так уже в таблицах.** Половина малого бизнеса живёт в них, и переносить это в базу - отдельный проект без очевидной пользы.
4. **Объём умеренный.** До нескольких тысяч строк работает нормально.

Ключевое требование: таблица должна быть плоской. Одна строка - одна запись, шапка в одну строку, никаких объединённых ячеек и итогов посреди данных. Почему это критично и что ещё ломает автоматику, разбирал в материале про [живые графики вместо картинок](/guides/zhivye-grafiki-vmesto-kartinok).

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

## Когда без настоящей базы уже не обойтись?

**Главное**

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

| Признак | Файлы | Таблица | База |
|---|---|---|---|
| Пишет один человек | да | да | да |
| Пишут несколько одновременно | нет | нет | да |
| До тысячи записей | да | да | избыточно |
| Десятки тысяч записей | нет | плохо | да |
| Связанные данные | нет | плохо | да |
| Правка человеком без программиста | да | да | нужен интерфейс |
| Откатывается вместе с кодом | да | отдельно | нет |

Последняя строка - самая важная и самая неочевидная, поэтому ей отдельный раздел ниже.

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

Отдельно помнить: как только в базе появляются данные людей, включается регулирование, и разговор про хранение становится юридическим. Про этот переход есть отдельный разбор - [что делать, когда прототип готов](/guides/prototip-gotov-chto-dalshe-deploy-152fz).

## Что теряется при пересоздании базы?

**Главное**

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

Разберём механику, потому что она не очевидна.

Когда [вайбкодингом](/concepts/vibecoding) собираешь инструмент, агент по ходу работы меняет структуру хранения: добавляет поля, переименовывает, перестраивает. Иногда самый простой для него путь - пересоздать хранилище с нуля.

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

Обиднее всего, что предупреждения обычно нет. Агент сообщает, что перестроил структуру, и формально он прав.

Что с этим делать:

1. **Перед любой перестройкой спроси прямо**

   «Что будет с уже введёнными данными при этом изменении? Они сохранятся или пропадут?» Один вопрос, который экономит вечер.

2. **Сделай выгрузку до начала работ**

   Простой файл с содержимым таблиц. Это занимает минуту и спасает от любого сценария.

3. **Разведи тестовые и рабочие данные**

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

4. **Заведи регулярную копию**

   Как только данными пользуются, копия делается по расписанию, а не по вдохновению.

Про то, что откат кода не спасает данные, письма и внешние сервисы, я писал отдельно в материале про [откат изменений агента](/guides/kak-otkatit-izmeneniya-agenta).

## Как выбрать за пять минут?

**Главное**

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

Быстрый порядок для тех, кто не хочет разбираться:

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

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

## Три типовые ошибки хранения

**Главное**

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

**Ошибка первая: одно и то же в трёх местах.** Часть в таблице, часть в файлах, часть в чате. Возникает само собой и делает любую автоматизацию бессмысленной: непонятно, какая версия правильная.

**Ошибка вторая: хранение в переписке.** Списки, цифры и договорённости живут в диалоге с агентом. Разговор закончился - данные исчезли. Всё, что нужно завтра, должно быть записано в файл.

**Ошибка третья: нет копии.** Самая частая и самая дорогая. Проверяется одним вопросом: если сейчас пропадёт всё, откуда ты восстановишь данные. Нет ответа - нет и хранилища.

К этому же классу относится и хранение чувствительных сведений там, где им не место. Где проходит граница и что можно отдавать наружу, разбирал в материале про [документы компании и нейросети](/guides/chuvstvitelnye-dannye-i-neyroseti-v-kompanii).

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

**Главное**

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

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

**Нужно ли учить язык запросов к базе?**

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

**Можно начать с таблицы и потом перейти на базу?**

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

**Где хранить документы и картинки, а не строки?**

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

**При переносе на хостинг данные переедут сами?**

Нет. Код переезжает, данные - отдельная операция. Перед переносом делается выгрузка, после переноса - проверка, что записи на месте.

## Главный вывод

**Главное**

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

Ошибка новичка почти всегда в одну сторону: сложнее, чем нужно. Хочется взрослого решения, а нужен работающий инструмент.

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

Открой свой инструмент и ответь на один вопрос: если данные пропадут сегодня ночью, откуда ты их восстановишь?

### Источники

- [SQLite - официальная страница о том, для каких задач подходит встроенная база данных](https://sqlite.org/whentouse.html)
- [PostgreSQL - документация о резервном копировании и восстановлении базы данных](https://www.postgresql.org/docs/current/backup.html)
- [Реляционная база данных - обзорная статья о связанных таблицах, Википедия](https://ru.wikipedia.org/wiki/Реляционная_база_данных)
- [Резервное копирование - обзорная статья о копиях данных и их восстановлении, Википедия](https://ru.wikipedia.org/wiki/Резервное_копирование)
- [CSV - обзорная статья о текстовом формате выгрузки табличных данных, Википедия](https://ru.wikipedia.org/wiki/CSV)