Lesson Outline

Structuring Data in CouchDB

Time to build stuff! In this lesson, we are going to decide on the structure of the data for our application. We are going to make some decisions around what our documents will look like, but before we get to that we are going to talk through some considerations relevant to data structure in CouchDB.

Single Database vs Multiple Databases

We store documents in our CouchDB database, but it's also important to consider that the database itself can also play a role in the structure. When we think of databases we would usually think (at a small scale at least) of having a single database that all of our data is added to.

The idea of giving each user their own database in a typical relational database might sound out of the ordinary, but with CouchDB it is actually quite a common solution. CouchDB can easily handle creating thousands of databases, so giving each user their own database is actually a reasonable approach in a lot of circumstances.

So, we could implement a solution that looks like this:

Let's say you were creating a note taking application and you want the user's data to sync to a remote CouchDB database (so that they can access their data across multiple devices). If the user's notes are supposed to be private, how do we prevent other users from accessing them? Instead of implementing some complicated access control system, we can just give each user their own database. If we have 1,000 users, we have 1,000 CouchDB databases. This isn't an issue.

If we're creating something like Hangz where sharing data is a key feature, then it probably makes more sense to have a single shared database. This is the case for the application we are building, but what if rather than having a single shared space to share notices and chat, you wanted people to be able to create their own private spaces (maybe for specific friendship groups, or companies)? In that case, you could create a new CouchDB database for each group, rather than having a single shared database.

You could use any of these approaches, or even combine them, the main point I want to get across here is that creating 1,000 databases for your application might sound impractical, but when using CouchDB it certainly isn't.

Considerations when Structuring Data

Now let's discuss a few key concepts to keep in mind when structuring data in a document based NoSQL database. There are entire books dedicated to working with NoSQL databases, so I'm not intending for this to be all encompassing, I just want to touch on a few important points to get you into the NoSQL mindset. We will focus mostly on points that are going to be relevant to our applications database.

When Should You Create Documents?

When we want to store some data in our database, we can create a document. But it's important to consider when to create a new document, and when to add data to an existing document. Technically speaking, you could create a single document and store all of the data for the entire application in that one document - this would be a terrible idea, but it's possible, and highlights the fact that we need to know when to create a new document.

As we have discussed, a document usually contains all the relevant data for something in one place (like an invoice). With that in mind, we might create a new document to add to our database in the following circumstances:

• A user creating a note
• A user adding a todo
• A user creating a blog post
• A user creating a new invoice
• A user adding a post to their social feed

These seem like reasonably obvious instances where we could create separate documents for each note, todo, blog post, and so on. It's not always so obvious, though, what about in the case of someone adding a comment to a social post? Does the comment exist as its own document, or do we add the data for the comment to the post's document?

A great example to consider is that of posts in a blog. A typical document for a blog post might look something like this:

{
	"_id": "some-blog-post",
	"_rev": "4-5cc274e03d0ef2e451325ba0ee3ef01a",
	"type": "post",
	"title": "Some Blog Post",
	"content": "Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.",
	"author": "Josh Morony",
	"datePublished": "2017-03-20T05:10:57.757Z",
	"dateUpdated": "2017-03-20T05:10:57.757Z"
}

Now let's say we want to add the ability for users to add comments to specific blog posts. Do these comments exist as their own document, or do we add them to the document for the blog post?

We could add comments to the posts document like this:

{
	"_id": "some-blog-post",
	"_rev": "4-5cc274e03d0ef2e451325ba0ee3ef01a",
	"type": "post",
	"title": "Some Blog Post",
	"content": "Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.",
	"author": "Josh Morony",
	"datePublished": "2017-03-20T05:10:57.757Z",
	"dateUpdated": "2017-03-20T05:10:57.757Z",
	"comments": [
		{
		   "author": "Josh Morony",
		   "content": "nice post!",
		   "datePublished": "2017-04-03T01:13:57.936Z"
		},
		{
		   "author": "Natasha",
		   "content": "agreed!",
		   "datePublished": "2017-04-03T01:13:57.936Z"
		}
	]
}