[dahart]

I don't know of any mandatory books or theory about NoSQL, I picked it up on the fly using Firebase for a web app. Not affiliated, but I'm a reasonably happy customer. It's super easy to learn, and they have lots of tips and pointers about how to use it well, as I'm sure others do.

Their tips are here, and I think this applies to most/all NoSQL (someone correct me if I'm wrong.) https://firebase.google.com/docs/database/web/structure-data

The tl;dr is:

- Avoid complex queries. Structure data so that you can make simple queries that execute fast.

- Avoid nesting & flatten data as much as is reasonable.

NoSQL is easier to learn & use than SQL, there's lower barrier to entry, but the trade off is that it's less powerful than SQL, so you have to keep your data simple too.

[jklein11]

>Avoid nesting & flatten data as much as is reasonable.

Isn't this contradictory?

[dahart]

Yes, it is a little bit - if you mean that one reason to use NoSQL is to store nested JSON.

This is referring more to schema than data. In part what that means is to avoid nested indexes... subtle but different than avoiding any nesting at all. In other words, if you can treat the nested data as a blob, it's probably okay, but if it's being used for a query, it's adding complexity that can cause trouble.

Some of the reasons for that are Firebase-specific, it has to do with security rules and how security can get too complicated if you're not careful with nesting.

But I'd guess it still applies to other NoSQL data... nesting data as part of the schema is like making another table, and all the complexity that comes with it. Except it's a new table you can only get to by going through the first table.

A common problem with nesting is thinking you got the order right for your use case and later finding out you sometimes want to index by the inner data rather than the outer data. If you only have A/B (B nested in A) and you need to query for As, then you're fine. When you find out you need to query for Bs, you have a problem.

Firebase even recommends duplicating data, if necessary, to have two indexes A/B and B/A, rather than trying to query for nested data.

[jklein11]

It seems like this stackoverflow question hits on the same issue you ran into.[1]

It looks like that might be specific to Firebase's implementation because this can be achieved with Mongodb.[2]

1. https://stackoverflow.com/questions/27207059/firebase-query-...

2.https://stackoverflow.com/questions/15654228/sort-by-embedde...

[dahart]

No, that's not the issue I ran into. Their API has changed since this question was asked & answered to fix that particular issue.

The bigger issue remains that schema nesting causes a type of complexity that SQL dbs avoid by always being flat. Even that answer you linked to, the very last sentence is: the most important one for people new to NoSQL/hierarchical databases seems to be "avoid building nests".

Schema nesting in mongodb is also best avoided, if you can, e.g.:

https://stackoverflow.com/questions/5108790/mongodb-best-pra...