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

Коротко

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

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

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

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

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

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

Термины, которые встретятся по дороге, я собрал в отдельном словаре вайбкодинга.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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