For MarkLogic (and maybe for noSQL in general?), is it best to store parent-child as one document? Thus, if coming from a relational world, a normalized parent-child table will need to be denormalized and stored as a single document?
Will this design impact how searches are done (since children records now are searched always in the context of the parent)?
It might depend whether children can have multiple parents or not (e.g. graph-type data, instead of hierarchical), but my reasoning would be that for hierarchical data, storing it in its natural hierarchical form (using XML or JSON or such), makes most sense. It doesn't mean storing the entire parent-child table as one document, but rather expanding the records to its original trees, and storing those as documents.
This will not fit all NoSQL solutions, but will work well for those that fall into the document store category, particularly if they provide good search around contents and hierarchy.. like MarkLogic..
Note: graph-type data can be stored as triples inside MarkLogic. That will allow querying it with SPARQL, and inferencing over it for instance..
HTH!
It's not that the parent-child relationship is "denormalized", but rather the children are "merged" into the parent.
One thing to consider is the type of relationship you have. UML provides descriptions for different kinds of relationships - see Difference between association, aggregation and composition .
In general (exceptions exist), I think association and aggregation relationships will be between separate documents, whereas composition relationships will be "merged" into a single document.
Concrete example - a person knows many persons (association), a person can own many vehicles (aggregation, a vehicle only has one owner, but its own lifecycle), and a person can have many names (composition). I would create person and vehicle documents, but not name documents - I would store all the names on the person document.
To me, that's a big advantage of a document database over a relational database. In the latter, I'm forced to create separate tables no matter what kind of relationship I have. In a document database, I can choose what makes the most sense and fits my application's needs. Very often, my physical document model much more closely resembles my application's conceptual model.
