Stocker un graphique complet dans un SGBDR

Question

J'ai plusieurs types d'entités, chacune avec ses propres champs, qui sont stockés dans des tables séparées.
Chaque enregistrement d’une telle table peut être connecté à zéro ou plusieurs enregistrements d’une table différente, c’est-à-dire liés à des enregistrements de types d’entités différents.
Si j'utilise des tables de consultation, j'obtiens (m (m-1)) / 2 = O (m ^ 2) tables de consultation distinctes qui doivent être initialisées.
Même s'il est encore possible pour 6 ou 7 types d'entités différents, serait-il toujours pertinent pour plus de 50 types de ce type?
En particulier, un enregistrement donné doit avoir des liens vers la plupart des autres types d'entités, aussi théoriquement je traiterais d'un graphe presque complet, non orienté, à n côtés.

Quelqu'un peut-il nous éclairer sur la manière de stocker cette structure dans un SGBD relationnel?
(J'utilise Postgresql si c'est important, mais toute solution pour un autre SGBD serait également utile).
Merci pour votre temps!

Yuval

Answer 1

C’est un mappage relationnel-objet, un problème classique. Vous avez vraiment besoin d’un outil ORM pour le faire correctement, sinon il vous rendra fou.

Le problème de connexion auquel vous faites référence est l’un des pièges. Il nécessite une optimisation très minutieuse et un réglage des requêtes. Sinon, les performances seront annulées (par exemple, le problème N + 1 SELECT).

Je ne saurais être plus précis sans connaître votre plate-forme d'application. Le SGBD utilisé n'est pas vraiment lié au problème.

Answer 2

Vous pouvez utiliser un type de base commun pour tous les types d’entités et gérer les relations via ce type de base. C’est quelque chose que n'importe quel outil ORM peut faire avec une colonne discriminante et des relations de clé étrangère (je ne connais pas bien CLSA, cependant). ).

Cette approche vous laisse avec exactement une table de relations.

Modifier: Voici comment vous configurez ceci:

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
);

Notez la colonne discriminante ( type ) qui aidera votre solution ORM à trouver le sous-type correct pour une ligne ( type1 ou type2 ). La documentation de l’ORM devrait comporter une section sur la façon de mapper le polymorphisme avec une table de base.

Answer 3

L’autre option consisterait à utiliser une base de données orientée objet , telle que db40 ou Cache. Si les performances ne vous préoccupent pas vraiment et si vous êtes déterminé à stocker l'intégralité de votre graphe d'objet, il est peut-être intéressant de regarder vers cela.