Database Reference
In-Depth Information
MongoDB Parent Reference = RDBMS Self Referencing (Recursion at Physical Level)
Using the same sample employee data as above, let's look at MongoDB collections for
each of these hierarchies and networks. Note that we used the employeeFirstName as the
unique index and we are only storing the employee's first name (and sometimes manager
references), but it will illustrate how MongoDB handles recursion. Here is a collection
showing the hierarchy example using parent references:
Employee :
{ _id : "Mary", employeeFirstName : "Mary"
},
{ _id : "Bob", employeeFirstName : "Bob",
managerID : "Mary" },
{ _id : "Jill", employeeFirstName : "Jill",
managerID : "Mary" },
{ _id : "Ken", employeeFirstName : "Ken",
managerID : "Bob" },
{ _id : "Jane", employeeFirstName : "Jane",
managerID : "Bob" },
{ _id : "Sven", employeeFirstName : "Sven",
managerID : "Jill" }
Depending on the business requirements, we may decide to store the full management
chain with each employee as an array:
Employee :
{ _id : “Mary”, employeeFirstName : “Mary” },
{ _id : “Bob”, employeeFirstName : “Bob”, managerID : “Mary”, managerPath : [ “Mary” ] },
{ _id : “Jill”, employeeFirstName : “Jill”, managerID : “Mary”, managerPath : [ “Mary” ] },
{ _id : “Ken”, employeeFirstName : “Ken”, managerID : “Bob”, managerPath : [ “Mary”, “Bob” ] },
{ _id : “Jane”, employeeFirstName : “Jane”, managerID : “Bob”, managerPath : [ “Mary”, “Bob” ] },
{ _id : “Sven”, employeeFirstName : “Sven”, managerID : “Jill”, managerPath : [ “Mary”, “Jill” ] }
I would choose capturing the full manager path using arrays over just storing the immediate
manager when the requirements state the need to do analysis across an employee's com-
plete management chain, such as answering the question, “What is the complete chain
of command for Sven?” This trade-off is typical of the modeling choices the MongoDB
modeler faces: run-time processing versus data redundancy.
Search WWH ::




Custom Search