Хранение полного графа в РСУБД - PullRequest
Новая
       23

Хранение полного графа в РСУБД

1 голос
/ 28 сентября 2008

У меня есть несколько типов сущностей, каждый со своими полями, которые хранятся в отдельных таблицах.
Каждая запись в такой таблице может быть связана с нулем или несколькими записями в другой таблице, то есть связана с записями из разных типов объектов.
Если я использую таблицы поиска, я получаю (m (m-1)) / 2 = O (m ^ 2) отдельных таблиц поиска, которые необходимо инициализировать.
Хотя все еще возможно для 6 или 7 различных типов сущностей, будет ли это актуально для 50+ таких типов?
В частности, данная запись должна иметь ссылки на большинство других типов сущностей, поэтому, теоретически, я буду иметь дело с почти полным, ненаправленным, n-сторонним графом.
Может кто-нибудь пролить свет на то, как хранить эту структуру в реляционной СУБД?
(Я использую Postgresql, если это имеет значение, но любые решения для других СУБД были бы одинаково полезны).
Спасибо за ваше время!

Юваль

Ответы [ 3 ]

2 голосов
/ 28 сентября 2008

Вы можете использовать общий базовый тип для всех типов сущностей и обрабатывать отношения через этот базовый тип - это то, что практически любой инструмент ORM может сделать, используя столбец дискриминатора и отношения внешнего ключа (хотя я не знаком с CLSA, хотя ).

При таком подходе вы получаете ровно одну таблицу отношений.

Edit: Вот как это настроить: 

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 должен быть раздел о том, как отобразить полиморфизм с помощью базовой таблицы.

2 голосов
/ 28 сентября 2008

Это объектно-реляционное отображение, классически сложная проблема. Вам действительно нужен инструмент ORM, чтобы сделать это правильно, иначе он сведет вас с ума.

Проблема с подключением, на которую вы ссылаетесь, является одной из ловушек, и она требует очень тщательной оптимизации и настройки запросов, иначе это снизит производительность (например, проблема N + 1 SELECT).

Я не могу быть более конкретным, не зная, какова ваша прикладная платформа - фактически используемая СУБД не имеет отношения к проблеме.

0 голосов
/ 28 сентября 2008

Другим вариантом будет использование объектно-ориентированной базы данных , такой как db40 или Cache. Это может быть связано с тем, что производительность не очень важна, и вы полны решимости сохранить весь свой граф объектов.

...