I am about to develop a solution for a customer where the basic entity is a member and members can have different multiple social relationships with other members. For instance Lets say we have four types of members Doctors, Specialist, Nurses and Patients. So one or more Doctors can consult one or more Specialists, One or more Doctors can treat one or more Patients. One or more Doctor is in Charge of one or more Nurses. So if I were to use a Relational DB a high degree of recursion would be necessary (as All entities must be members). Whereas recursion is not necessary in a Graph data model.
Is it then safe to say it is better to use a Graph database for a social type application where members may have different or overlapping roles.
A graph database would be good at modelling these kinds of relationships. There's a few ways that you might model it. You could think of a vertex as being a Member with different edges from Member to other Members representing the types of relationships:
- Member --consults--> Member (physician to specialist)
- Member --reportsTo--> Member (nurse to physician)
- Member --diagnoses--> Member (physician to patient)
Obviously a Member may have as many of any edge type (e.g. multiple "consults" with specialists). In a more complex model, you might also see a Member as being an "identity" for a person such that your model looks like:
- Member --actsAsPhysician--> Physician
- Member --actsAsSpecialist--> Specialist
- Physician --consults--> Specialist
In this approach the "consults" edge can only exist on a "Physician" vertex, thus you provide some constraints as to what vertex types can be expected to have what kind of edges.
Graphs provide you a lot of flexibility in being able to model data such as it exists in the real-world as you are really just describing entities and the relationships among them. I'd encourage you to look at http://tinkerpop.com for a collection of tools that are helpful in building graph applications independent of the graph database you choose.
If every one is a member then member is central to the data model in a relational perspective. There is no need for recursive SQL select statements:
Member ->---<- Doctor ->---<- Patients
One or More Members is One or More Doctors One or More Doctors treats One or More Patients
Your model will have a lot of Many to Many relationships and alot of Relationship tables. For instance the Treats relation could contain attributes such as Treatment Period
Ailment
etc.
Your solution could be implemented in any topology. While the network/graph topology is faster than the Set topology the graph data model once implemented is almost impossible to change. History tells us it is unwise to build rigid business applications. So research the pros and cons of each and make a decision.
