NoSql Data Modeling with Firebase

Question

Im second guessing how I have modeled my data for a buy/sell app. Each Entity is stored as a node, which contains a list of that entity specified by unique id's.

• users -> userId -> [name: "joe", age: 21].

where it gets interesting is the way I store Items. First, I have an items node designed just like the example above. This way I can easily search for any item, or all items. This is handy because I can load all items and add business logic to to display items that can be categorized as Recently Added, Local, Trending etc. These are not nodes in the database.

Now, a user needs access to items they are personally involved with. This kind of item has its own node like so:

• selling -> userId -> itemId -> [title: "shoes", size: 11].

Other categories like buying, bought selling, sold liked, archive follow this pattern. It seems taxing to make changes/searches at so many locations in db when something happens. For instance, if a user wins an item(theres bidding), I have to remove from buying add to bought, add to archive, remove from all items, and for the user who sold the item do the inverse pretty much.

Is it normal to execute this many queries, or should items be more tightly related?

I'm using Firebase by the way. Thanks for your time

Answer 1

Is it normal to execute this many queries, or should items be more tightly related?

Since Firebase doesn't have server-side joins, it is quite common to do joins from the client. This is in itself not always a performance problem, since Firebase pipelines the requests over a single connection.

But it's also quite common to duplicate some of the data to prevent/reduce the number of joins. You'll require a strategy to (or event whether) to keep the duplicated data in sync.

A final alternative is to preload certain data. While that likely doesn't apply here, it can be quite common if the list where you look up from is relatively short, e.g. the list of categories for items.