Tagging – various approaches in CouchDB

I finished my last post by raising the issue that there are many ways to approach structuring data in CouchDB. The same applies to the standard RDBMS of course, but in that case the wrongs and rights are clearer even if that’s only because we’ve seen it all before.

On a related note, I get the impression a lot of people are jumping into CouchDB because they don’t like or can’t get their head around the RDBMS. That’s not a great surprise, since in many cases (mostly web apps) the RDBMS is being both misused, and in an application it’s not best suited for in the first place. My advice is this – if you “hate SQL” or “can’t get your head around it”, go back and figure it out, because there’s no doubt that the RDBMS is one of the finest and most well developed tools we have in software today. If you don’t see that, you probably aren’t best placed to make the decision about what kind of database is appropriate to your application, and worse still I predict you’ll end up having the exactly same kind of relationship with CouchDB.

Anyway, I set out to give some concrete examples of how you might approach tagging in CouchDB. In my last post I created a simple MySQL database, where the tagging structure boils down to this:

We have a table for our items, a table for our tags, and each tag applied to an item results in an entry to the link table. For an extreme application (either very small or very big) something else might be appropriate, but for the most part I would argue this is “the right way” to do it. The key point about this layout is that given a document, we can efficiently find all the tags applied to it, and vice versa.

So what are the options for representing this same data in CouchDB? Starting at the very simplest level, we can just define our document like this:

The tags field is just a list of textual tags. This would be a heinous crime in an RDBMS, but in CouchDB we can query this very efficiently by defining a view to do it. An obvious drawback though is that we can’t have any metadata about our tags. More importantly, we have to define our views to search for a specific tag. If we know what tags we’ll be using at design time, this could be a very good approach, but if they’re arbitrary and numerous, it’s no good at all. The limiting factor is that views can’t be parameterised in any way (although see below), so if you’re going to search for tag ‘x’ you’ll have to define a view for it. It’s worth noting that temporary views are cached in the same way as permanent ones, so using that approach would be efficient except for the first time you queried a particular tag, but still it’s not good for most situations.

Here’s another effort:

Now we can have metadata for our tags, and if we have the relevant tag document we have a list of items tagged with that tag. The simplest method would be to get all the tag documents back, which we can do easily by defining a view like this:

function(doc) {
  if(doc.type=="tag")
    return doc;
}

This might be ok if we don’t have a lot of tags and associated metadata, but if we do, we might just want that specific tag document. Although I said above that you can’t have parameterised views, in fact, you can achieve pretty much the same thing as follows:

function(doc) {
  if(doc.type=="tag")
    return {key:doc.name};
}

The above view uses the name as the key, rather than the usual ID, and that allows use to use the startkey and endkey query parameters when retrieving the view. Setting them both to the desired tag value will return either one row (the tag we want) or zero if it doesn’t exist. The row only contains the document ID, revision and key though, so a second lookup is then necessary to get the actual document.

Needless to say, the above layout doesn’t help much when we want to go the other way around and given an item document, find what tags are attached to it. In fact, if you take this to its logical conclusion you end up with the same structure as the original RDBMS table layout I started with, and you will be making a lot of extra effort on the client side that was dealt with in the RDBMS world with a simple SQL query.

This is far from being a criticism of CouchDB. Firstly, I’ve taken an inherently relational problem which is obviously not what CouchDB is going to excel at. Secondly and more importantly, the increased effort necessary is the cost of the other benefits of CouchDB. I think I’d still find it worthwhile in this scenario in exchange for easy scaling, redundancy and fault tolerance.

An option not considered here, though workable in both the RDBMS and CouchDB scenarios, is using full-text search to implement tagging. A further possibility is that I’m missing something about CouchDB, which is not impossible since I’m new to it. Time will tell on that one, but so far I am liking what I see.