Is it reasonable to create a join object when using a NoSQL database?

Let's say I want to tag various objects like companies, users, time-series data. I know ahead of time that I will want to do queries like find all companies with tag X.

Now, I could just add a tag row to every object, then MapReduce an answer to the query.

Or, I could discard the row and create a TagAssociation object, which would associate a Tag ObjectID with another ObjectID (e.g. Company, User, TimeSeries). Then I could do these queries faster, and with no MapReduce. But then I feel like I'm just using RDBMS practices with a friendly NoSQL interface. Are these join objects in NoSQL a re开发者_如何学编程asonable practice, or am I not using NoSQL properly?

What you are describing is actually an index - storing a list of items with a particular tag in advance to speed up queries. There are easier/more idiomatic ways to set up an index.

Also, have you thought about how you would query the TagAssociation object? Wouldn't that still be using MapReduce to query the Tag and Company properties?

Typically map/reduce is used on VERY large datasets and not for a quick I need this info kind of thing. For that people set up self made indexes(sometimes map/reducing them out of the current data).

Another way to go is playOrm which can do joins and such (BUT on partitions NOT on the whole table). In this fashion, if you could get the partition for January or a partition for Account 1234 and query into it with normal SQL and join it with something else. playOrm does the indexing for you using typical noSQL indexing patterns behind the scenes.

later, Dean