Question

I am currently working on an application where we are basically building up a graph between “items”.
I think there are different kinds of links between those items, but I am struggeling right now to decide how to model those, especially bi-directional links.

1. Example:

ItemB --isChildOf---> ItemA
ItemA --isMasterOf--> ItemB

The same I think could be modelled like this:

Example 2

ItemA <---> ItemB

In my Database model I currently model my links like this:

* sourceID
* targetID
* relationType (e.g. isMasterOf, isChildOf, maybe more...)

Do I also need the direction as a field in my table? So far I don’t have it as a separate field, because IMO the direction is implicitly defined by sourceID and targetID.

I am not sure in which situations I would need Example 1 and in which cases Example 2 is enough. I think Example 1 is like twitter, where UserA can follow userB but maybe not the other way round. Facebook on the other hand is always Example2 in my opinion.

Hope my question makes sense.

Answer 1

If you want a solution that is as generic as possible and will work in any simple graph modeling case (one-to-many/many-to-one, many-to-many), just model the links as (source_id, target_id) pairs in a separate link table. That way you can both

• model bidirectional links by having edge pairs (a.id, b.id) and (b.id, a.id) and unidirectional links by having one of those depending on direction
• differentiate edge direction by looking at which node is the source and which is the target – no need to have a separate direction field.

If you want to make an elegant solution for a particular case where there are actual constraints on what kind of graph you want to model, you will first need to decide

1. what kind of links you want to allow between objects: will they always be uni- or bidirectional, or do you need to differentiate both and
2. whether it will be a tree-like structure where one object can have just one parent but many children, or a more generic graph where one object may have several edges coming and going.

Regarding the first point, if you KNOW all the links will be of the same kind, you don’t really need to differentiate edge (source_id, target_id) from edge (target_id, source_id) in the code, because both mean just an edge between two objects/nodes.

As far as the second point goes: if the graph you want to model resembles a tree or a forest (every object has 0 or 1 parents and 0 to n children, all the links are of the same type – uni- or bidirectional), you can just add something like parent_id to the objects themselves instead of modeling the connections on a separate link table.

Obviously, if you need to have other attributes to the edges (such as weight or some kind of type attribute other than direction), you’ll have to add fields accordingly. In that case it would make most sense to model the edges on a separate table in any case, since the edges will not be just simple links between nodes but objects with actual properties.