The Logical Type of The Document in CouchBase

Question

How should the logical type of a document get specified in CouchBase? Using a field for the type? Or employing separators in keys like product::app::123id?

Currently I'm putting a document type, inside the document itself, inside a string field named Type like say Product.

But I see this pattern of using separators in document id, like product::app::123id. Done some playing around it, couldn't get the type part (product) from the key (Of-course parsing it, by splitting is possible, which to me seems to have same overhead in both N1QL and views).

So how should the document type (app logic type) get specified?

Env: CouchBase Community, inside Docker on Ubuntu 14.04, using Go client gocb.

Answer 1

I talked about this recently in my blog post on data modeling.

It really depends on how your application will be interacting with your documents. If you're going to use a lot of N1QL, it probably makes sense to use the 'type' field like you are doing. (I don't know what tooling is available for Go, but Linq2Couchbase can help you manage this 'type' field).

However, if you plan to use direct key access a lot (because it's faster or it makes more sense to do so from your application(s)), then you might want to use a meaningful key to convey relationships or other information. E.g. if I have a "product::123", then I can infer that "product::123::locations" is a related document. I don't think there is a way to get "product" from that type of key without some kind of string parsing overhead (SPLIT or SUBSTR N1QL functions). Though it may be possible to design an index for that? You may want to ask the wizards in our N1QL forum.

Or it might make sense to do a combination of both. In general, there isn't a right or wrong way to design your keys. It really depends on the data access patterns you want to use.