I’m new to the concept of nosql databases and have never used it. Based on what I’ve read and the little that I’ve understood I still don’t see how they can be particularly useful if you can’t make references between data, if there’s no concept of foreign key.
How would I forexample query something simple as ‘find all the comments posted by this user’, ‘find all photos that belong to an album entity’ etc.
Do nosql systems move away from the static relational data-model but still let you keep track of such references, is there something analogous to foreign keys that you can utilize in queries?
General Uses
-
If you have data structures that are not clearly defined at the time when you make the system. I tend to keep user settings in nosql, for example. Another example was a system where the users needed to be able to add fields at runtime – very painful in an RDBMS and a breeze in NoSQL.
-
If your model structure is largely centered around one or few model objects and most relationships are actually child objects of the main model objects. In this case you will find that you will have fairly little need for actual joins. I found that contact management system can be implemented quite nicely in nosql for example. A person can have multiple addresses, phones and e-mails. Instead of putting them each into a separate table, they all become part of the same model and you have one person object.
-
If you want to benefit from clustering your data across multiple servers rather than having one monolithic server, which is commonly required by RDBMS.
-
Caching. Even if you want to stick with a RDBMS as your main database, it can be useful to use a NoSQL database for caching query results or keeping data, such as counters.
-
Storing documents. If you want to store coherent documents, in a database some of the NoSQL databases (such as MongoDB) are actually specialized in storing those.
What about joins?
Honestly, the no join thing sounded quite scary to me too in the beginning. But the trick is to stop thinking in SQL. You have to actually think with the object you have in memory when you are running your application. These should more or less just be saved into the NoSQL database as they area.
Because you can store your full object graph, with child objects, most of the need for joins is eliminated. And if you find you need one, you will have to bite the bullet and fetch both objects and join in your application code.
Luckily, most drivers can do the joining for you, if you set up your schema right.
For further reading I actually recommend Martin Fowler.
I would definitely use such a database during the planning stages of a project (before development, before even design) to record data whose structure, relationships, and characteristics are not yet known and subject to analysis. I would try to make everything fit a relational model after that.
3
In some cases, you won’t need foreign keys. For instance:
Find all the comments posted by this user
can be as simple as loading the comments part of a document corresponding to a user. This is called denormalization: instead of having two sets with a join, you have one document and everything you need is inside the document. One query, no joins, better performance.
But in some circumstances, this may lead to data duplication, so linking from one to another document could be suitable. In this case, you may be interested by MongoDB normalization, foreign key and joining, Database References page and especially DBRefs feature.