Memorizzazione di un grafico completo in un RDBMS

Question

Ho diversi tipi di entità, ognuna con i propri campi, che sono memorizzati in tabelle separate.
Ciascun record in tale tabella può essere collegato a zero o più record in una tabella diversa, vale a dire, collegato a record di diversi tipi di entità.
Se vado con le tabelle di ricerca, ottengo (m (m-1)) / 2 = O (m ^ 2) tabelle di ricerca separate che devono essere inizializzate.
Sebbene sia ancora possibile per 6 o 7 tipi di entità diversi, sarebbe comunque rilevante per oltre 50 di questi tipi?
In particolare, un dato record dovrebbe avere collegamenti con la maggior parte degli altri tipi di entità, quindi teoricamente avrei a che fare con un grafico quasi completo, non diretto, lato n.
Qualcuno può fare luce su come archiviare questa struttura in un DBMS relazionale?
(Sto usando Postgresql se è importante, ma qualsiasi soluzione per altri DBMS sarebbe ugualmente utile).
Grazie per il tuo tempo!

Yuval

Answer 1

Questo è Mapping relazionale di oggetti, un problema classicamente difficile. Hai davvero bisogno di uno strumento ORM per farlo correttamente, o ti farà impazzire.

Il problema di connessione a cui ti riferisci è una delle insidie ??e richiede un'attenta ottimizzazione e ottimizzazione delle query, altrimenti ucciderà le prestazioni (ad esempio il problema N + 1 SELECT).

Non posso essere più specifico senza sapere qual è la tua piattaforma applicativa - l'attuale DBMS utilizzato non è realmente rilevante per il problema.

Answer 2

È possibile utilizzare un tipo di base comune per tutti i tipi di entità e gestire le relazioni attraverso quel tipo di base: questo è qualcosa che praticamente qualsiasi strumento ORM può fare utilizzando una colonna discriminante e relazioni con chiave esterna (non ho familiarità con CLSA, sebbene ).

Questo approccio ti lascia esattamente con una tabella di relazioni.

Modifica: Ecco come configurarlo:

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

Prendi nota della colonna del discriminatore ( type ) che aiuterà la tua soluzione ORM a trovare il sottotipo corretto per una riga ( type1 o type2 ). La documentazione ORM dovrebbe avere una sezione su come mappare il polimorfismo con una tabella di base.

Answer 3

L'altra opzione sarebbe quella di utilizzare un Database orientato agli oggetti come db40 o Cache. Potrebbe essere utile esaminare questo aspetto se le prestazioni non sono un grosso problema e si è determinati a memorizzare l'intero grafico degli oggetti.