Когда структура базы данных выходит за пределы «простой таблицы», начинается настоящая инженерия. Особенно если речь идёт о работе с масштабируемыми каталогами, где тысячи или сотни тысяч записей не просто хранятся — с ними работают ежедневно: делают фильтрацию, формируют карточки товаров, подключают внешние системы. Одна из задач — перестроить базу данных, чтобы не просто "хранилась", а эффективно обслуживала бизнес-задачи. В этой статье — кейс оптимизации БД медицинского каталога и объяснение, почему была выбрана нормализованная архитектура и как она помогает в реальной работе.
От таблицы «catalog2025» к масштабируемой архитектуре
Начальный этап проекта был построен на базе таблицы catalog2025, которая, по сути, объединяла в себе всю бизнес-логику:
catalog2025
├── id (int) PRIMARY
├── name (text) – наименование товара
├── unit (varchar) – единица измерения
├── quantity (int) – количество
├── description (text) – описание
├── category_id (int) – ID категории
├── groups_id (int) – ID группы
├── status (tinyint) – статус публикации
На небольшом объёме и с фиксированным числом параметров такая структура работала стабильно. Однако при попытке адаптировать её под каталог медицинских товаров, особенно таких, как шовный материал, стали проявляться ограничения:
- Невозможно гибко описывать характеристики (например, длина нити, тип иглы, форма изгиба, материал и т.д.)
- Поля либо не используются, либо перегружаются, создавая дублирование
- Сложность фильтрации по параметрам и отображения в интерфейсе
- Невозможность масштабирования — если добавить ещё 10 параметров, таблица распухает
Типичная проблема: сложная категория с множеством параметров
Пример из реальной задачи — шовный материал. Один только товар может иметь:
- Тип хирургической нити
- Форму иглы
- Кривизну
- Длину иглы
- Длину нити
- Материал
- Тип покрытия
- Цвет
- Упаковку (количество в пачке, тип стерилизации)
И это — только одна категория из двадцати. Подход с одной таблицей становится архитектурным тупиком.
Новая структура базы данных: нормализация и гибкость
Решением стало построение нормализованной архитектуры, где вся информация разбивается по смысловым сущностям. Это даёт гибкость, масштабируемость и высокую производительность. Ниже — итоговая структура:
catalog_products — основные товары
catalog_categories — категории (например, шовный материал, перевязочные средства)
catalog_subcategories — подкатегории (нитки с иглой, без иглы, рассасывающиеся и т.д.)
catalog_brands — бренды (Ethicon, B. Braun, Медполимер)
catalog_attributes — параметры (длина нити, изгиб иглы, цвет)
catalog_attribute_values — значения параметров (75 мм, 3/8 круга, синий)
product_attributes — связь товара и параметра
product_images — изображения
product_prices — цены, валюта, скидки
Связи между таблицами
Например, товар с ID 123 может иметь:
product_attributes: (123, 'длина иглы', '25 мм')product_attributes: (123, 'тип иглы', 'колющая, обратная')product_prices: (123, 375.50, 'BYN')product_images: (123, 'img_123_front.jpg')
Фильтрация осуществляется по атрибутам и значениям. Это ускоряет SQL-запросы, позволяет строить сложные фильтры и масштабировать количество характеристик без изменения схемы таблиц.
Примеры SQL-запросов
Получение всех параметров товара
SELECT a.name, v.value
FROM product_attributes pa
JOIN catalog_attributes a ON pa.attribute_id = a.id
JOIN catalog_attribute_values v ON pa.value_id = v.id
WHERE pa.product_id = 123;
Поиск всех шовных материалов с иглой 3/8 круга
SELECT p.*
FROM catalog_products p
JOIN product_attributes pa ON p.id = pa.product_id
JOIN catalog_attributes a ON pa.attribute_id = a.id
JOIN catalog_attribute_values v ON pa.value_id = v.id
WHERE a.name = 'кривизна' AND v.value = '3/8 круга';
Почему это важно
- Производительность: таблицы не перегружены, каждый запрос чётко оптимизирован
- Масштабируемость: можно безболезненно добавлять новые параметры и категории
- Гибкость: система подходит и для медицинских товаров, и для техники, и для одежды
- Чистота архитектуры: поддерживать такой проект проще, он читаем и расширяем
Итог: правильная архитектура ускоряет не только сайт, но и бизнес
То, что начиналось как проект с простой таблицей, перешло в полноценную архитектуру, пригодную для масштабируемых медицинских решений. Именно благодаря перепроектированию базы данных стало возможно:
- Подключать внешние системы
- Ускорить фильтрацию и загрузку
- Обеспечить поддержку роста до миллионов записей
- Формировать карточки товаров динамически на основе атрибутов
Сложная структура — не проблема, если база данных спроектирована правильно. Архитектура — это не просто таблицы. Это основа всей логики взаимодействия.
Следующий уровень — автоматизация ввода данных, генерация шаблонов карточек товаров на базе характеристик и интеграция с медицинскими справочниками. База данных готова. Пора двигаться дальше.