Диетолог ведёт дневники питания клиентов: своя база вместо чужих таблиц

MAATRIX

Дневник питания — это не список продуктов, это подробная и часто неудобная история отношений человека с едой: срывы, вес, самочувствие, иногда диагнозы и назначения врачей. У большинства диетологов и нутрициологов эта история годами живёт в Google Таблицах — по одной вкладке на клиента в одном общем файле или, того хуже, в одной огромной таблице на всех сразу. Работает, пока клиентов десять. Когда их пятьдесят, а доступ к файлу есть у ассистента, бухгалтера и бывшего партнёра по кабинету — это уже не рабочий инструмент, а риск, который вы просто пока не заметили. Ниже — как устроена приватная база дневников на собственном сервере, где каждый клиент видит только свою историю, а у вас остаётся структурированный обзор по всем сразу.

Чем на самом деле плоха общая таблица для дневников питания

Формально в Google Таблицах есть права доступа: можно дать «только просмотр», можно ограничить конкретной вкладкой. На практике всё разваливается на первом же неудобстве. Кто-то из ассистентов получает доступ «ко всему файлу, чтобы не путаться» — и вот уже человек, который занимается расписанием, технически может открыть вкладку с историей срывов совершенно постороннего клиента. Ссылку на файл легко переслать в мессенджер, не подумав, что открывший её увидит не только нужную вкладку, а всё содержимое. Табличные права доступа по вкладкам в бесплатных сервисах либо отсутствуют, либо требуют платного тарифа с администрированием, до которого у практикующего специалиста обычно просто не доходят руки.

Отдельная проблема — где физически лежат эти данные. Google, как и любой другой облачный сервис, может в любой момент поменять условия использования, временно заблокировать аккаунт по формальному признаку (спам-фильтр, подозрительная активность, жалоба) или просто оказаться недоступным в нужный момент. Для сравнения фото или текстового документа это неприятно. Для истории пищевого поведения клиента, которую вы обязаны держать конфиденциально просто по профессиональной этике, — это принципиально другой уровень ответственности, потому что вы теряете контроль над тем, кто и при каких обстоятельствах может получить доступ к чувствительным данным о здоровье. Разница между «файл в чужом облаке с настроенными правами» и «данные на инфраструктуре, которую администрируете лично вы» — это разница между предположением и гарантией.

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

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

Что меняется с собственной базой на сервере

Идея простая: вместо одного общего файла с вкладками — база данных с чёткой структурой, где каждый клиент физически видит только свои записи, а вы работаете с общим интерфейсом поверх всех клиентов сразу. Технически это делается через связку СУБД (PostgreSQL) и no-code слоя поверх неё — например, NocoDB или Baserow, — который превращает таблицы базы в удобные веб-формы и списки без необходимости писать собственное приложение.

Разница с электронными таблицами не только в приватности, но и в структуре данных. В Google Таблицах дневник — это плоский лист, где всё держится на дисциплине и договорённостях («записывай сюда, формат такой»). В базе данных структура задаётся один раз на уровне схемы: у записи дневника обязательно есть клиент, дата и приём пищи, и система физически не даст сохранить запись без этих полей или перепутать, к какому клиенту она относится. Ошибка «скопировал не ту вкладку» здесь просто невозможна как класс — потому что вкладок в привычном смысле больше нет, есть строки с внешним ключом на конкретного клиента.

Структура базы: какие таблицы нужны диетологу

Для практики диетолога/нутрициолога разумная схема — это не одна таблица, а несколько связанных:

• Clients — карточка клиента: имя, дата начала работы, контакты, цель (снижение веса, набор массы, коррекция рациона при заболевании), заметки о противопоказаниях и назначениях врача.
• Diary_Entries — записи дневника: дата, приём пищи (завтрак/обед/ужин/перекус), что съедено, порция, самочувствие после еды. Связана с Clients по client_id.
• Measurements — периодические замеры: вес, объёмы, при необходимости показатели анализов, дата замера. Тоже привязана к client_id.
• Recommendations — рекомендации и корректировки плана от вас, с датой, чтобы была видна история изменений, а не только последняя версия.

Такая структура даёт то, чего плоская таблица не даёт в принципе: можно построить представление «все клиенты с пропуском записей за последние три дня» одним фильтром, а не пролистыванием тридцати вкладок. В NocoDB и Baserow это делается через фильтрованные вьюхи (views) — сохранённый фильтр по таблице Diary_Entries, группировка по client_id, сортировка по дате последней записи.

Как ограничить каждому клиенту доступ только к своему дневнику

Здесь стоит быть честным: open-source версии NocoDB и Baserow не дают из коробки полноценного построчного доступа «этот пользователь видит только строки со своим client_id» так, как это делают крупные корпоративные CRM с ролевой моделью. Но рабочий и достаточно надёжный способ есть — через фильтрованные shared views.

Механика такая: вы создаёте отдельную вьюху по таблице Diary_Entries (и, при желании, Measurements) с фильтром client_id = <конкретный клиент>, а затем публикуете эту вьюху как отдельную share-ссылку с паролем. Клиент получает персональную ссылку и пароль — и видит только записи, которые проходят через фильтр, то есть только свои. Он не может открыть общий список клиентов, не видит структуру базы целиком, у него нет доступа ни к чему за пределами этой конкретной отфильтрованной вьюхи. В NocoDB такую вьюху можно дополнительно сделать редактируемой только в части ввода новой записи (форма для внесения приёма пищи) и запретить редактирование или удаление чужих полей.

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

Сравнение: общая таблица против своей базы

Установка и первые шаги

Практический путь — поднять на VPS PostgreSQL как хранилище и NocoDB (или Baserow, они закрывают похожую задачу немного разными интерфейсами) поверх него в Docker Compose. Для практики на несколько десятков активных клиентов с ежедневными записями дневника достаточно скромной конфигурации — 2 vCPU и 2-4 ГБ RAM с запасом под рост базы и вложения (если планируете прикреплять фото порций к записям, они займут больше места, чем текст).

Порядок действий:

1. Разворачиваете PostgreSQL и NocoDB в docker-compose — это стандартная связка, подробный пошаговый разбор есть в отдельной статье про установку NocoDB на Ubuntu 24.04.
2. Создаёте таблицы Clients, Diary_Entries, Measurements, Recommendations и связи между ними через внешние ключи по client_id.
3. Строите форму для внесения записи дневника — простая веб-форма с полями «дата», «приём пищи», «что съедено», «самочувствие», без необходимости клиенту разбираться в интерфейсе таблиц.
4. Для каждого клиента создаёте фильтрованную вьюху и share-ссылку с паролем, как описано выше.
5. Себе оставляете общий рабочий вид: таблицу всех клиентов с последней датой записи, фильтр по тем, кто давно не отмечался.

Если сомневаетесь между NocoDB и Baserow — разница в основном в интерфейсе и лицензионной модели, само по себе решение задачи дневников питания одинаково реализуемо в обоих; сравнение по функциям и удобству есть в статье NocoDB или Baserow — что выгоднее и когда. Если хотите начать с самого фундамента — с чистой установки PostgreSQL без надстройки, это отдельный шаг, разобранный в статье про установку PostgreSQL на Ubuntu 24.04.

Резервные копии и что делать, если сервер недоступен

Своя инфраструктура — это не только контроль, но и ответственность за то, чтобы данные не потерялись из-за вашей же ошибки или сбоя сервера. Минимальная разумная схема — ежедневный pg_dump базы по cron с хранением нескольких последних копий локально и хотя бы одной копией за пределами самого сервера (в объектном хранилище или на другой машине), чтобы отказ одного диска не означал потерю всей истории дневников за годы работы.

# пример cron-задачи: дамп базы каждую ночь в 3:00,
# хранение 14 последних копий
0 3 * * * pg_dump -U nocodb_user nocodb_db | gzip > /backups/dietolog_$(date +\%F).sql.gz
find /backups -name "dietolog_*.sql.gz" -mtime +14 -delete

Это не отменяет разговор о шифровании резервных копий, если в них есть чувствительные данные о здоровье клиентов — при переносе копии за пределы сервера имеет смысл шифровать архив (например, gpg с симметричным ключом) до того, как он покинет машину, а не полагаться только на приватность канала передачи.

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

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