Лекция
Реляционные базы данных остаются фундаментом информационных систем благодаря своей строгой логике, поддержке транзакций и универсальности. Однако внутри реляционной модели существует несколько различных подходов к организации хранения данных, которые позволяют адаптировать структуру под конкретные задачи.
Классическая нормализованная модель обеспечивает целостность и минимизацию дублирования, но может быть сложной для высоконагруженных систем. В противоположность ей, денормализованная модель жертвует строгой структурой ради ускорения доступа. Для гибких сценариев, где заранее неизвестно количество атрибутов, применяется EAV-модель (Entity–Attribute–Value). В случаях, когда требуется хранить полуструктурированные данные, реляционные СУБД поддерживают JSON/XML/LOB-колонки, совмещая преимущества SQL и NoSQL. Кроме того, существуют подходы для специфических задач: широкие таблицы для фиксированных, но разнообразных атрибутов, Pivot-модели для аналитики и иерархические структуры для представления деревьев и категорий.
Внутри реляционных баз данных (SQL) существует несколько способов организации хранения данных, помимо EAV. Они различаются по структуре таблиц и подходу к моделированию:
Принцип: данные разбиваются на связанные таблицы (1NF, 2NF, 3NF и выше).
Особенности: минимизация дублирования, строгая структура, удобство для транзакций.
Пример: таблица Customers и отдельная таблица Orders, связанные по ключу.
Принцип: часть данных хранится в одной таблице для ускорения запросов.
Особенности: больше дублирования, но меньше JOIN-операций.
Пример: таблица заказов сразу содержит имя клиента и его адрес.
Принцип: создается таблица с очень большим количеством колонок, часть из которых может быть пустой.
Особенности: удобно для фиксированных, но разнообразных атрибутов.
Пример: таблица с сотнями колонок для разных характеристик товара.
Принцип: данные хранятся в колонках типа JSON, XML или BLOB.
Особенности: гибкость как у NoSQL, но внутри реляционной СУБД.
Пример: PostgreSQL JSONB, Oracle XMLType.
Принцип: похожа на EAV, но значения группируются по колонкам, а не по строкам.
Особенности: используется для аналитики, когда нужно динамически разворачивать данные.
Пример: таблица, где строки превращаются в динамические колонки через PIVOT.
Принцип: хранение деревьев и иерархий в реляционной таблице.
Особенности: удобно для категорий, меню, организационных структур.
Пример: таблица Categories с колонкой Parent_ID.
Способы хранения иерархических структур в реляционных базах данных:
Materialized Path (он же Path Enumeration, materialized path pattern) — когда у узла хранится строка с полным путем от корня до него (у тебя это path_keys: region:eu|difficulty:normal|...).В русскоязычных командах часто говорят просто: “материализованный путь” / “храним путь в поле”.
Nested Sets — это lft/rgt.
Adjacency List — это parent_id.
Closure Table — отдельная таблица всех связей предок-потомок.
Вот сравнительная таблица основных способов хранения данных внутри реляционных баз данных:
| Метод хранения | Принцип | Преимущества | Недостатки | Применение |
|---|---|---|---|---|
| Нормализованная модель | Данные разбиваются на связанные таблицы (1NF–3NF+) | Минимизация дублирования, строгая структура, поддержка транзакций | Много JOIN-операций, сложность запросов | Классические бизнес-приложения, бухгалтерия, CRM |
| Денормализованная модель | Дублирование данных для ускорения доступа | Быстрые запросы, меньше JOIN | Избыточность, риск несогласованности | Аналитика, отчеты, системы с высокой нагрузкой |
| EAV (Entity–Attribute–Value) | Атрибуты и значения хранятся построчно | Гибкость, легко добавлять новые свойства | Сложные запросы, слабая типизация | Медицинские системы, каталоги товаров |
| Wide Tables (широкие таблицы) | Таблица с большим числом колонок | Простота структуры, быстрый доступ к фиксированным данным | Много пустых значений, трудности расширения | Системы с фиксированным, но разнообразным набором атрибутов |
| JSON/XML/LOB хранение | Данные хранятся в колонках формата JSON, XML, BLOB | Гибкость как у NoSQL, хранение сложных структур | Ограниченная оптимизация, сложность индексации | Конфигурации, хранение полуструктурированных данных |
| Pivot-модель | Данные разворачиваются в динамические колонки | Удобно для аналитики, гибкая агрегация | Сложность реализации, нагрузка на сервер | BI-системы, отчетность |
| Иерархическое хранение (Adjacency List, Nested Sets) | Хранение деревьев и иерархий | Удобно для категорий и структур | Сложные обновления при изменении структуры | Категории товаров, оргструктуры, меню |
Таким образом, реляционные базы данных предоставляют не один универсальный способ хранения, а целый набор методов, каждый из которых оптимален в определенных условиях. Их грамотное сочетание позволяет создавать системы, одновременно устойчивые, гибкие и производительные. Например, EAV — лишь один из способов, а рядом с ним есть нормализация, денормализация, хранение JSON/XML, широкие таблицы и специальные модели для иерархий.
Комментарии
Оставить комментарий
Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL
Термины: Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL