Nachschlage-/Referenztabellen in Graphdatenbanken

Question

Wie modellieren/repräsentieren wir Nachschlage-/Referenztabellen in Graphdatenbanken?
Ein spezieller Fall: Master-Übersetzungstabelle (enthält Nachschlagedaten für viele der Kerntabellen).
Sollten wir sie in Kerntabellen zusammenführen? RDBMS representation

Answer 1

Sie könnten dies mit nur Knoten modellieren. Etwas wie:

CREATE (:Translation{code:'SLD', description:'some lengthy description'}) 
CREATE (:Translation{code:'NY', description:'New York'}) 
CREATE (:Translation{code:'USA', description:'United States'}) 
CREATE (:Address{address:'123 Street St', state:'NY', country:'USA'}) 

Und für die Nutzung vielleicht so etwas wie:

MATCH (p:Person)-[:LIVES_AT]->(a:Address) 
WHERE id(p) = 101 
OPTIONAL MATCH (state:Translation{code:a.state}) 
OPTIONAL MATCH (country:Translation{code:a.country}) 
RETURN a.address as address, state.description as state, country.description as country 

Das heißt, ich glaube, eine Graphdatenbank die Notwendigkeit für diese etwas veraltet macht. Es scheint mir, dass der Grund, diese zu verwenden, darin besteht, Speicherplatz zu sparen, da die gleichen Werte wiederholt verwendet werden, so dass es in RDBMS sinnvoll ist, nur die längere Beschreibung an einem Ort zu behalten.

Mit einer Grafik, die Sie vorschlagen, scheint sollte den Wert seiner eigenen Knoten extrahieren und erstellen Sie Beziehungen, um es, wie folgt aus:

CREATE (ny:State{code:'NY', name:'New York'}) 
CREATE (usa:Country{code:'USA', name:'United States}) 
CREATE (a:Address{address:'123 Street St'}) 
CREATE (a)-[:IN_STATE]->(ny) // or a more generic :IN if desired 
CREATE (a)-[:IN_COUNTRY]->(usa) // or a more generic :IN if desired 

Die Abfrage wäre dann:

MATCH (p:Person)-[:LIVES_AT]->(a:Address) 
OPTIONAL MATCH (a)-[:IN_STATE]->(state) 
OPTIONAL MATCH (a)-[:IN_COUNTRY]->(country) 
RETURN a.address as address, state.name as state, country.name as country 

Sie werden feststellen, dass dies sehr ähnlich aussieht. Der Name des langen Landes ist immer noch nur an einem Ort gespeichert. Der wahre Unterschied ist der Kontext, sowohl für das Arbeiten mit Knoten mit bestimmten Beschriftungen als auch für möglicherweise spezifischere Eigenschaftsschlüssel und für die Tatsache, dass die Beziehung zu diesen Knoten Teil Ihres Datenmodells ist, anstatt bestimmte Eigenschaftsfelder irgendwie kennen oder erraten zu müssen in einem anderen Knoten nachgeschlagen (versuchen Sie beispielsweise CALL db.schema() im Browser).

Dies erleichtert auch das Nachschlagen von Adressen nach dem Code, wenn Sie einen Index hinzufügen: Status (Code) und: Land (Code).