Хранение полного графа в СУБД
У меня есть несколько типов сущностей, каждая со своими полями, которые хранятся в отдельных таблицах.
Каждая запись в такой таблице может быть связана с нулем или несколькими записями в другой таблице, т. Е. Связана с записями из разных типов сущностей.
Если я использую таблицы поиска, я получаю (m (m-1)) / 2 = O (m ^ 2) отдельные таблицы поиска, которые необходимо инициализировать.
Хотя это все еще возможно для 6 или 7 различных типов сущностей, будет ли это актуально для 50+ таких типов?
В частности, данная запись должна иметь ссылки на большинство других типов сущностей, поэтому теоретически я буду иметь дело с почти полным, ненаправленным, n-сторонним графом.
Может ли кто-нибудь пролить свет на то, как хранить эту структуру в реляционной СУБД?
(Я использую Postgresql, если это важно, но любые решения для других СУБД были бы одинаково полезны) .
Спасибо за уделенное время!
Юваль
Ответы 3
Это объектно-реляционное сопоставление, классически сложная задача. Чтобы сделать это правильно, вам действительно нужен ORM-инструмент, иначе он сведет вас с ума.
Проблема с подключением, о которой вы говорите, является одной из ловушек, и она требует очень тщательной оптимизации и настройки запросов, иначе она снизит производительность (например, проблема N + 1 SELECT).
Я не могу быть более конкретным, не зная, какая у вас платформа приложения - фактическая используемая СУБД на самом деле не имеет отношения к проблеме.
Другой вариант - использовать Объектно-ориентированная база данных, например db40 или Cache. Это может быть рассмотрено, если производительность не является большой проблемой, и вы полны решимости сохранить весь граф объекта.
Вы можете использовать общий базовый тип для всех типов сущностей и обрабатывать отношения через этот базовый тип - это то, что может сделать практически любой инструмент ORM, используя столбец дискриминатора и отношения внешнего ключа (хотя я не знаком с CLSA).
При таком подходе остается только одна таблица отношений.
Редактировать: Вот как вы это настраиваете:
CREATE TABLE base (
id int(10) unsigned NOT NULL auto_increment,
type enum('type1','type2') NOT NULL,
PRIMARY KEY (id)
);
CREATE TABLE type1 (
id int(10) unsigned NOT NULL,
PRIMARY KEY (id),
CONSTRAINT FK_type1_1 FOREIGN KEY (id) REFERENCES base (id)
);
CREATE TABLE type2 (
id int(10) unsigned NOT NULL,
PRIMARY KEY (id),
CONSTRAINT FK_type2_1 FOREIGN KEY (id) REFERENCES base (id)
);
CREATE TABLE x_relations (
from_id int(10) unsigned NOT NULL,
to_id int(10) unsigned NOT NULL,
PRIMARY KEY (from_id,to_id),
KEY FK_x_relations_2 (to_id),
CONSTRAINT FK_x_relations_1 FOREIGN KEY (from_id) REFERENCES base (id),
CONSTRAINT FK_x_relations_2 FOREIGN KEY (to_id) REFERENCES base (id)
ON DELETE CASCADE ON UPDATE CASCADE
);
Обратите внимание на столбец дискриминатора (type), который поможет вашему решению ORM найти правильный подтип для строки (type1 или type2). В документации ORM должен быть раздел о том, как сопоставить полиморфизм с базовой таблицей.
И я все равно смогу сохранить разные таблицы сущностей, или мне нужно будет как-то уместить все свойства в одной таблице? Я здесь немного запутался ...