CODEWITHSUNDEEP
couchbasedatabasenosql
discodane
discodane

Reputation: 2095

Couchbase: nosql db document design for nested layers of data

CONTEXT:

I have a data set that has deep nested information. There 5 layers. The top layer has a list of the second, the second has a list of the 3rd etc etc etc.

I have different users that will have access levels to all the different data. IE top level users will have access to the top layer and all layers underneath. 2nd level user will have access to the 2nd level and all layers below it, 3rd to 3rd and so on to the bottom level only have access to that level.

I currently have a DB that only holds the top level of information. There are 8 documents on the top level. So if a level 2 or 3 user logs in, I get the level 1 data that pertains to them and then in the server side code, I filter the data to only what the users needs and then send it up.

Question:

I've heard that good nosql db design would be to design the documents based on the server api. With my data this seems like it would create a lot of redundant data. For example, data for a user level 5( the lowest level ) would be included in some level 4 data, who's same data would be included in a level 3 data, all the way up, all in different documents.

Is this a none issue that we just don't really care about? Or am I thinking about this issue wrong?

Upvotes: 0

Views: 207

Answers (1)

Roi Katz
Roi Katz

Reputation: 575

You should think about access patterns to you data.

True, it may cause redundant data - but we are living in the information age.

The real concern here is the velocity you want to access your data. The fastest way is one document for each level- but then you have

  • Redundant data
  • Nested document
  • Slower updates
  • Fastest reads

If you need a lot of updates, + you need it consistent you may want to break it to smaller documents. The way of doing it is to design the key of the document to have a relation to the parent and a reference to the child in the parent. It is very common modus operandi in Couchbase as you can choose the key as you wish.

  • No redundant data
  • Pieces of documents, several gets per document
  • Fast updates - only update small fraction
  • Slower reads, several gets per document (or join if you are using N1QL)

You can also mix and match the references + embedding - depending the use case.

Upvotes: 1

Related Questions