Hi Kalin,
I'm not sure I follow about duplicating. The suggestion I made did not
involve any duplicating. The AssetType nodes would contain properties
appropriate to the type of asset, and the Asset node would contain
properties only appropriate to that instance (or none if none are
appropriate). Perhaps it is easier if I rather revert back to your original
names, and use Asset for the type again, and come up with a new name for the
specific instance? Then you get something like:
Producer[1] --(contributes_to)--> [X] <--(subscribes_to)-- Consumer1
|
(IS_A)
|
V
Asset[P] <--(subscribes_to)-- Consumer2
Now you can see that the X is really just like a join table in a relational
database. In fact my suggestion is very similar to a common refactoring that
occurs in a relational database when you have a foreign key to another table
and then need to add properties to that relationship, you create an
intermediate 'join table' and add the properties there.
I definitely still think you will need to expand your
producer-asset-consumer triple to be a producer-x-asset-consumer, where the
'x' is the 'join table' that allows a consumer to subscribe to assets by a
particular producer. Which is what you want, right?
I will answer, based on my model suggestion, each of the queries you ask
below:
1. Given a Consumer, what Assets does it subscribe to?
>
Traverse from consumer along both outgoing 'subscribes_to' and outgoing
'is_a' relationships, and you will get all assets regardless of whether the
consumer subscribes to the asset in general, or the specific producer-asset.
> 2. Given a Consumer, what Producers is it dependent upon?
>
Traverse from consumer along outgoing 'subscribes_to', incoming 'is_a' and
incoming 'contributes_to' relationships, and you will get all producers of
all assets (specific or otherwise) that the consumer subscribes to.
> 3. Given a Producer, what Assets does it contribute to?
>
Traverse from producer along outgoing 'contributes_to', and outgoing 'is_a'
relationships, and you get the Assets they they contribute to.
> 4. Given a Producer, what Consumers are dependent on it?
>
Traverse from producer along outgoing 'contributes_to', outgoing 'is_a'
relationships and incoming 'subscribes_to' and you get all Consumers that
depend on assets that producer contributes to. This one is more subtle,
though, because it depends on what you mean by 'dependent on'. Since the
traverser I described will not exclude consumers that subscribe_to assets
that are produced by both the given producer and others also (giving the
consumer the choice of producer). If you only want consumers that have no
choice, leave the 'is_a' relationship out of the traverser.
> 5. Given an Asset, what Producers contribute to it and what Consumers
> subscribe to it?
>
For producers traverse on incoming 'is_a' and incoming *contributes_to'. For
consumers traverse on incoming 'is_a' and incoming 'subscribes_to'.
There's other node types and properties within the graph that aren't
> important or that I can't discuss (this is a mock model anyway).
>
Hopefully the fact that I renamed my AssetType back to your original Asset,
and have a new 'join table', possibly called 'producer-asset' for the
additional concept I added before will make it easier to see how to fit this
model into your existing structures.
What is the consensus about duplicating node data within a network? I can
> see how using indexing or a hierarchy, as you've pointed out, might help
> with that.
> Part of my hangup is that I'm looking at using Neo4J as an adjunct to a
> RDBMS to store dependency relationships. Each node will have information
> that ties back to the RDBMS for lookups. But that doesn't require absolutely
> unique nodes. Keeping the two DBs in sync will be a challenge but I don't
> have the option to push all of the data into Neo4J and I'd rather not manage
> the dependencies in the RDBMS.
>
I dislike duplicating data in neo4j as much as I dislike duplicating it in a
RDBMS. I'm sorry if I gave the impression in my previous email that I was
suggestion duplication. My suggestion was just the addition of this
'join-table' idea (an extra node in the graph), so make it possible to
capture the concept of a consumer subscribing to an asset and an asset by a
particular producer.
Actually, now that I've talked around it, I think I see how your model would
> work for what I want to do. I'd have to see how a Traverser would return the
> results.
> Thanks for your time,
>
Super. Perhaps I should have read your complete mail before writing this new
one.... or hopefully the new one, especially all the traverser suggestions,
has helped clarify further ? :-)
Regards, Craig
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
