2 ms·

I guess an example of what I am talking about is a user's profile. Say I have a user account, which has a profile. That profile data is stored in a NoSQL docume

by weeksie 17y ago

I guess an example of what I am talking about is a user's profile. Say I have a user account, which has a profile. That profile data is stored in a NoSQL document store. Now I want to get all of the profiles that are over 30 and match them with (for example, I'm reaching here) interests that are indexed by age bracket. How do I find and match my over 30 users with their interests? The example itself is a poor one but illustrates my confusion at how to go about building an entire app in a NoSQL db.

astine 17y ago
I'd hand code a tagging system. I'd create arbitrary tag/category pairs, associate them with users and sort them into persistent maps stored by user, category and tag. Ultimately, if you want to add relational features to a non-relational store, you need to model the relations explicitly rather than relying on the underlying features of the store.
- weeksie 17y ago
  Cheers, thanks for that. I figured that was essentially the way to solve the problem. That said, I imagine that I'll be using a combination of both document stores and SQL databases on my next (largish) project.
nicpottier 17y ago
Ya, I think there are definitely cases where it becomes very burdensome to use a NoSQL setup. Certainly anything where you are wanting to do analysis in the DB doesn't work very well. In your particular case I guess you'd have to do two queries. One to grab the users in the range you have, then another to grab the interests for that range. One interesting bit is that you could fire those off in // if you so wished, then do the merge. As I said earlier, it does kind of require you to really think through your access patterns ahead of time before going the NoSQL route. And at least in SimpleDB there is no doubt not being able to query across 'tables' can be a big letdown. But really it is those kinds of queries that eventually turn into problems, so to some extent it just forces you to think of the right way of doing things first. (I know, and agree that optimize last is usually a better strategy)

by weeksie 17y ago

astine 17y ago

I'd hand code a tagging system. I'd create arbitrary tag/category pairs, associate them with users and sort them into persistent maps stored by user, category and tag. Ultimately, if you want to add relational features to a non-relational store, you need to model the relations explicitly rather than relying on the underlying features of the store.

weeksie 17y ago
Cheers, thanks for that. I figured that was essentially the way to solve the problem. That said, I imagine that I'll be using a combination of both document stores and SQL databases on my next (largish) project.

nicpottier 17y ago

Ya, I think there are definitely cases where it becomes very burdensome to use a NoSQL setup. Certainly anything where you are wanting to do analysis in the DB doesn't work very well. In your particular case I guess you'd have to do two queries. One to grab the users in the range you have, then another to grab the interests for that range. One interesting bit is that you could fire those off in // if you so wished, then do the merge. As I said earlier, it does kind of require you to really think through your access patterns ahead of time before going the NoSQL route. And at least in SimpleDB there is no doubt not being able to query across 'tables' can be a big letdown. But really it is those kinds of queries that eventually turn into problems, so to some extent it just forces you to think of the right way of doing things first. (I know, and agree that optimize last is usually a better strategy)