4.3. Система хранения данных

Архитектура хранения данных разделена на два уровня: уровень файлового хранения для справочной информации и уровень реляционной базы данных для операционной информации. JSON-файлы clinics.json и appointments.json служат в качестве простого и эффективного хранилища для данных, которые редко изменяются и часто читаются. Формат JSON был выбран за его читаемость, простоту парсинга и широкую поддержку в экосистеме Python. Файл clinics.json содержит структурированную информацию о медицинских учреждениях: их идентификаторы, названия, адреса, контактные данные, описания и перечни предоставляемых услуг с ценами. Эта информация загружается в память при запуске сервера и служит источником данных для каталога клиник.

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

Реляционная база данных MySQL используется для хранения критически важных операционных данных. Таблица users содержит учётные записи зарегистрированных пациентов с информацией об имени пользователя, email и пароле. Таблица appointments_log реализует логирование, фиксируя каждую успешную запись на приём с указанием пользователя, клиники, врача, времени и стоимости. Этот лог является неизменяемым — записи в него только добавляются, но не изменяются или удаляются, что обеспечивает достоверность исторических данных. Таблица orders хранит информацию о заказах услуг из корзины, включая состав заказа в формате JSON и общую стоимость.

4.4. Схема базы данных

Схема базы данных была спроектирована с учётом требований нормализации данных и обеспечения целостности. Таблица users использует числовой автоинкрементный идентификатор в качестве первичного ключа, что является стандартной практикой в реляционных базах данных. Поле username имеет ограничение уникальности, предотвращающее регистрацию пользователей с одинаковыми именами, а также индекс для ускорения поиска при аутентификации. Хранение паролей в открытом виде (в текущей учебной реализации) является сознательным упрощением; в production-системе следовало бы использовать криптографические хеши.

Рисунок 1 - Схема базы данных

Таблица appointments_log спроектирована как журнал событий, что отражается в наличии временных меток (created_at) и отсутствии внешних ключей (в учебных целях). Каждая запись в этой таблице представляет собой неизменяемый факт совершения записи на приём. Такой дизайн соответствует принципам event sourcing и позволяет восстанавливать историю изменений без риска потери данных. Поля clinic_name и doctor хранятся как строки, а не как ссылки на нормализованные таблицы, что является денормализацией, оправданной для журнальных таблиц, где важна неизменяемость и читаемость данных.

Таблица orders демонстрирует гибридный подход к хранению данных: основная информация о заказе (идентификатор, пользователь, сумма) хранится в нормализованном виде, а состав заказа (список услуг с количеством и ценами) сохраняется как JSON-строка в поле items_json. Этот компромисс между реляционной и документной моделью позволяет сохранить гибкость структуры заказа (разное количество позиций, произвольные атрибуты услуг) без усложнения схемы базы данных дополнительными таблицами связи. В production-среде стоило бы рассмотреть использование нативного типа данных JSON, поддерживаемого современными версиями MySQL.