Hi Jack,
Neo4j like the other nosql databases is by default schema free.
We started to add some optional constraints (property uniqueness, property
existence) and* plan to add more* (cardinalities, types, ranges).
For default values, I would not store them but produce them (if needed) at
query time with coalesce(n.property, "default-value")
For relationships, as it is equally fast to navigate a relationship in
either direction, you only need one of them (not two in either direction).
If you have conceptionally a bidirectional relationship like KNOWS, you can
just leave off the arrow tip for the direction.
For property hierarchies, I'd derive them from higher up, either with a
custom procedure / function ala " derived("property",nodes-to-root)" or
with a construct like this:
MATCH path = (child)-[:PARENT*..5]->(root:Root {id:0}) WHERE NOT
(child)<-[:PARENT]-()
RETURN reduce(value=null, c in nodes(path) | case value when null
c.property else value end ) as derived_value
HTH
Michael
On Mon, Jan 9, 2017 at 5:21 AM, <[email protected]> wrote:
> Hi All,
>
> I've just started poking around neo4j and it looks like it could be a good
> fit for some aspects of data governance/mdm, but I was wondering about some
> features that I have not yet seen discussed.
> I worked on a POC in a relational database using an extended EAV model
> combined with Solr indexes for fast searching. It worked pretty well, but
> the complexity associated with the abstraction of the data model is
> definitely a downside. neo4j /graph db looks like a perfect solution for
> some of the challenges encountered with the relational design, but it
> appears to be missing some of the desired capabilities. I admit that I am
> having a little trouble with the paradigm shift from relational to graph; I
> feel that I am getting close, but hitting a wall. Perhaps some of my
> solution would exist in a graph db and some outside of it.
> I'll spill a list below and welcome any comments, ideas, links, insults,
> etc.
>
> property definitions: data types, value constraints
> (min/max/enumerations), required flag, default values, preferred data
> source(s), property-level security, usage restrictions, etc.
> ** would these be defined in "Property" nodes of a separate graph, or
> lookup files, or neo4j configuration? Schema looks almost right here, but
> we don't need neo4j to enforce these things, we just want to identify
> violations that require action.
>
> similarly, relationship definitions: constraints (this label can only
> relate to like labels, or different labels, or certain labels), required
> relationship properties, relationship types, etc,
>
> it looks like relationships only go one direction (based on the John,
> Sally, Book example)? So a peer-to-peer relationship would require 2
> relationships, one for each direction? If we treat a relationship as
> parent-child, is it just as easy/efficient to query for a child's
> parent/grandparent as it is for a parent's children/grandchildren?
>
> proper hierarchy definitions: I've read the neo4j propaganda citing org
> charts as proof that hierarchies are never perfect, but we desire true
> "single path from any leaf to the root" hierarchy definitions for product
> data. Probably just a different version of the same questions above, but
> I'm interested in examples of these.
>
>
> I guess that's all I have for now. I'll keep poking around for my own
> answers but appreciate any information.
>
> Thank you,
> Jack
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Neo4j" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
