Come memorizzare 1: n riferimento personale (dipendenze) nel database relazionale

Question

Come memorizzare 1: n riferimento personale (dipendenze) nel database relazionale

#1 da (3 voti)

2

Che cos'è un modo pulito per archiviare elementi che fanno riferimento a più altri articoli dello stesso tipo in un database relazionale?

Supponiamo di avere un elenco di file jar e delle relative dipendenze:

package1 depends on package2,package3
package2 depends on package3
package2 depends on nothing

Ora posso memorizzarlo in un database come segue

CREATE TABLE packages (
   pid STRING NOT NULL PRIMARY KEY,
   name STRING NOT NULL,
   dependencies INTEGER NOT NULL -- foreign key
)
CREATE TABLE dependencies (
   did STRING NOT NULL PRIMARY KEY,
   dependent INTEGER NOT NULL, -- foreign key
   dependentOn ??? 
)

Ma ciò non sarebbe normalizzato e cambiare una relazione significa toccarle tutte. Come potrei farlo meglio?

database-design

posta icehawk 20.02.2016 - 21:15

fonte

1 risposta

Leggi altre domande sui tag database-design

Consistenza transazionale con chiamate API esterne stampa in modalità vs stampa nella classe principale / driver

score 3 · Accepted Answer

Per rispondere alla domanda specifica che hai chiesto, il solito modo di modellare una dipendenza 1: N su un database relazionale normalizzato consiste nel mettere il link sul lato N. Ciò significherebbe, in questo caso, l'aggiunta di una sorta di colonna "dipende da" nella tabella del pacchetto (denominarla tuttavia ha senso per te) e non creare una seconda tabella.

Tuttavia, e andando oltre la specifica domanda per il problema che stai cercando di risolvere, direi che le dipendenze sono generalmente relazioni M: N. Anche nel tuo esempio, package3 appare due volte nell'elenco delle dipendenze ¹. Inoltre, non sai mai quando realizzerai un package4 che dipende anche da package2 , il che ti obbligherebbe a riscrivere il database per supportare (improvvisamente) il link M: N. Quindi, lo modellerei personalmente avendo un'altra tabella come

CREATE TABLE dependencies (
    dependent INTEGER NOT NULL, -- foreign key
    dependentOn INTEGER NOT NULL -- foreign key 
)

Penso che avere un ID di dipendenza come nel tuo esempio sia un po 'superfluo in questo caso.

¹ Supponendo che si intenda package1 dipende da package3 per mezzo di package2 , sarebbe in effetti una relazione 1: N, ma in tal caso non si stabilirà una diretta collegamento tra package1 e package3 nel database.