Ветклиника и карточки животных: своя база вместо тетради и облака

MAATRIX

Приём идёт, хозяин с котом на руках уже стоит у стойки, а администратор листает бумажную тетрадь в поисках записи о прошлой вакцинации — или открывает третью вкладку в облачной таблице, потому что вчера завели новый лист «на всякий случай». Знакомая картина для небольшой ветклиники: карточки животных живут где угодно, кроме одного места, где их можно быстро найти. Решение не требует ни дорогой ветеринарной MIS, ни ИТ-отдела — своя база пациентов на арендованном сервере поднимается за пару часов и остаётся полностью под контролем клиники.

Почему тетрадь и общая таблица не спасают ветклинику

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

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

Есть и более практичный аргумент: данные о клиентах клиники — это не только карточки животных, но и контакты владельцев (телефон, адрес, иногда паспортные данные для платных услуг). Эти данные обрабатываются на серверах стороннего облачного сервиса, условия которого клиника обычно не читала и точно не контролирует. О том, где законно держать сервер с персональными данными и как это соотносится с 152-ФЗ, если клиника хранит контакты клиентов и не только их, стоит почитать отдельно — тема касается любого бизнеса, который ведёт базу людей, а не только животных: 152-ФЗ простыми словами.

Что должно быть в карточке животного, чтобы врач не терял время

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

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

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

NocoDB и Baserow: конструктор базы без самописного сайта

Заказывать разработку отдельного веб-приложения под ветклинику избыточно — это месяцы работы и бюджет, которого у небольшой клиники обычно нет. Разумный средний вариант — self-hosted no-code платформа поверх настоящей реляционной базы данных: она даёт интерфейс, похожий на таблицу (привычно администратору), но под капотом — PostgreSQL или MySQL с настоящими связями между записями, поиском, фильтрами и одновременным многопользовательским доступом без конфликтов правок.

Два основных кандидата — NocoDB и Baserow. Оба разворачиваются в Docker на своём сервере за один compose-файл, оба дают спреадшит-интерфейс с формами, фильтрами и представлениями (views), у обоих есть ролевая модель доступа на уровне базы и таблицы. Разница между ними в деталях — быстроте интерфейса, гибкости форм, наборе полей и API — и для ветклиники не критична: любой из двух инструментов закроет задачу карточек животных. Если сомневаетесь, какой выбрать, сравнение с конкретными различиями есть здесь: NocoDB или Baserow — что выгоднее и когда. Дальше в статье используется NocoDB как рабочий пример — сама логика разворачивания у обоих инструментов аналогична.

Такой подход отличается от заказной ветеринарной MIS (medical information system) тем, что клиника не привязывается к чужому облаку и чужому прайсу за пользователя — сервер и данные свои, а конструктор бесплатный и с открытым кодом. Плата — за то, что часть узкоспециализированной ветеринарной логики (например, автоматический расчёт дозировки препарата по весу) придётся либо не автоматизировать, либо добавлять формулами вручную. Для клиники с одним-тремя врачами это разумный компромисс.

Разворачиваем сервер и поднимаем базу: пошагово

На арендованном VPS (для клиники хватает конфигурации на 2 vCPU и 4 ГБ RAM с запасом на годы вперёд — база с карточками животных весит немного даже с фотографиями снимков) поднимается связка NocoDB и PostgreSQL через Docker Compose.

Минимальный docker-compose.yml:

version: "3.8"
services:
  db:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_DB: vetclinic
      POSTGRES_USER: vetadmin
      POSTGRES_PASSWORD: ЗАМЕНИТЕ_НА_СЛОЖНЫЙ_ПАРОЛЬ
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    networks:
      - vetnet

  nocodb:
    image: nocodb/nocodb:latest
    restart: always
    depends_on:
      - db
    environment:
      NC_DB: "pg://db:5432?u=vetadmin&p=ЗАМЕНИТЕ_НА_СЛОЖНЫЙ_ПАРОЛЬ&d=vetclinic"
    ports:
      - "8080:8080"
    volumes:
      - ./nc-data:/usr/app/data
    networks:
      - vetnet

networks:
  vetnet:

Запуск:

docker compose up -d

После старта NocoDB доступен на порту 8080. Дальше стоит закрыть прямой доступ к порту извне и повесить сервис за обратный прокси с HTTPS — иначе логин администратора клиники будет уходить по незашифрованному каналу. Достаточно nginx с сертификатом Let's Encrypt и правила в firewall:

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw deny 8080/tcp
ufw enable

Порт 8080 остаётся доступен только через localhost, наружу смотрит только 443 через nginx, который проксирует запросы на 127.0.0.1:8080. Первый вход в NocoDB создаёт аккаунт владельца базы — с него дальше раздаются права остальным сотрудникам клиники.

Как разложить данные по таблицам, чтобы искать за секунды

Смысл собственной базы теряется, если просто перенести структуру старой таблицы один в один — с тем же винегретом из тридцати колонок в одной сущности. В NocoDB стоит развести данные по нескольким связанным таблицам:

Такая структура даёт то, чего не было в тетради и таблице: открыв карточку животного, врач сразу видит связанный список всех визитов и вакцинаций без ручного поиска — это работает через встроенные связи (linked records) NocoDB. Поиск по кличке, номеру чипа или фамилии владельца — обычная строка поиска, которая проверяет все таблицы сразу. Отдельно стоит завести представление (view) с фильтром «ревакцинация в ближайшие 30 дней» — администратор открывает его с утра и обзванивает владельцев без дополнительной работы.

Загрузку файлов (снимки, результаты анализов) NocoDB поддерживает как вложения прямо в поле визита — при небольшом объёме снимков этого достаточно; если клиника делает много рентгена или УЗИ и файлы тяжёлые, разумнее держать их отдельно на файловом хранилище, а в карточке визита оставлять только ссылку.

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

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

Резервное копирование — не опция, а обязательный пункт, если в базе единственный экземпляр истории болезни всех пациентов клиники за годы. PostgreSQL бэкапится штатным pg_dump, запущенным по расписанию:

#!/bin/bash
docker exec -t $(docker ps -qf "name=db") \
  pg_dump -U vetadmin vetclinic > /backups/vetclinic_$(date +%Y%m%d).sql
find /backups -name "vetclinic_*.sql" -mtime +30 -delete

Добавленный в cron скрипт (0 3 * * * /opt/vetclinic/backup.sh) снимает копию каждую ночь и хранит последние 30 дней. Важно, чтобы копии не лежали только на том же диске, что и рабочая база, — при отказе диска сервера пропадёт и база, и её бэкап одновременно. Разумная схема — копировать архив дампов на отдельное хранилище или на второй сервер. Подробный разбор автоматизации резервного копирования баз данных с разными сценариями восстановления — в отдельной статье: автоматизация резервного копирования баз данных.

Отдельный вопрос — данные владельцев животных. Это персональные данные в юридическом смысле (ФИО, телефон, иногда адрес), и клиника, которая их собирает, формально попадает под требования к обработке персональных данных так же, как любой другой бизнес с базой клиентов. Держа базу на своём сервере, а не в стороннем облачном сервисе с непрозрачными условиями обработки, клиника как минимум точно знает, где физически находятся эти данные и кто к ним имеет доступ.

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