Очень часто за основу архитектуры приложения берётся дерево. Простой пример: есть страны, в странах — области, в областях — города, в городах — организации, в организациях — работники, товары или что-либо ещё. Использование дерева вполне логично и оправдано. Иерархичность такой системы показывает некая абстрактная таблица. Назовём её object:
CREATE TABLE object (
id NUMBER(11),
parent_id NUMBER(11),
type VARCHAR2(16) NOT NULL,
name VARCHAR2(255) NOT NULL,
CONSTRAINT pk_object PRIMARY KEY (id),
CONSTRAINT fk_object_parent FOREIGN KEY (parent_id) REFERENCES object (id) ON DELETE CASCADE ENABLE
);
Наполним её какими-нибудь данными:
id | parent_id | type | name
------------------------------------------------------
1 | NULL | country | Россия
2 | 1 | region | Московская область
3 | 1 | region | Новосибирская область
4 | 2 | city | Москва
5 | 3 | city | Новосибирск
При этом мы можем легко одним запросом получать нужные нам связи:
-- Выбрать все города России
SELECT *
FROM object
WHERE type = 'city'
START WITH id = 1 CONNECT BY PRIOR id = parent_id;
-- Выбрать страну, в которой находится Новосибирск
SELECT *
FROM object
WHERE type = 'country'
START WITH id = 5 CONNECT BY PRIOR parent_id = id;
Однако проблемы появляются, когда записей в таблице становится на столько много, что любой рекурсивный запрос выполняется минуты две, а то и больше. Менять всю архитектуру как-то поздновато… Тут-то нам на помощь и приходит денормализация дерева. В этой статье я расскажу об одном из способов такой денормализации.
Читать полностью »
