Database Reference
In-Depth Information
Alternative approaches to importing data
into Neo4j
Theirstthing everyone should understand is that in a connected world, importing
datais,perdeinition,moredificulttodo.Itisatrue
knot
thatisterriblydificultto
untie for many different reasons, but that does not mean that we cannot untie it!
Logically, the problem of importing
connected
dataistechnicallymoredificult
than with
unconnected
data structures. Importing unconnected data (for example,
thenodesofyourgraphmodel)isalwayseasy/easier.Justdumpitallinthere.
However, you then come to importing the connections and relationships, and you
indthatthere'snosuchthingasan
external entity
(also known as
the database
schema
) that will ensure the consistency and connectedness of the import. You
have to do this yourself, and explicitly by importing the relationships between
the following:
• Astartnodethatyouhavetoind
• An end node that you have to look up
This process is just inherently more complicated than what it would be in other
data models, especially at scale.
Sohowdoweuntiethisknot?Wecanreallyseetwostepsthateveryoneneedsto
take in order to do so:
•
Understand the import problem
: Every import is different, just like every
graph is different. There is little or no uniformity there, and in spite of the
fact that many people would love to just have a silver bullet solution to this
problem, the fact of the matter is that there is none. Therefore, we will have
to
create
a more or less complex import solution for every use case using
one of the tools at hand. However, like with any problem, understanding
the import problem is often the key to choosing the right solution, and this
is what we will focus on here as well.
