How do relations work in NOSQL?

Question

I was using SQL in all my previous application and to understand the Parse.com db storage, I wanted to know NOSQL.

I tried searching the differences between SQL and NOSQL for past 2 days & I still don't understand how a relation works in NOSQL.

I learned that NOSQL is schemaless and there's no structure like SQL. Let me brief my question in an example.

Example :

In a SQL application for School management, I would create a table students which stores students' information. For marks, I'll have a marks table which has a column user_id that refers to students table. I'll have one more table subjects which will hold sub_id, sub_code and subject_name.

So, if I change sub_code in the subjects table, that will simply reflect to the other tables where FOREIGN KEY is used by using ON UPDATE DELETE CASCADE.

Now my question is,

since NOSQL doesn't use NORMALIZATION, how will the data be stored? Should a single table (document in NOSQL) hold all the information that is in students table, marks table and subjects table?

If we dump all the information into one single table, how efficient will it be?

If we want to change a subject code, then we need to update all the documents, right? (In SQL, we simply change subject code in one table, since other columns in other table which are referencing this column subject code will simply update right rather than updating each single entries?)

Answer 1

In your question you are using "SQL" and "relational" to mean the same thing. In the same way you can think of "NoSQL" as meaning "not relational" i.e. there is no primary key / foreign key concept; there is no "normalisation" enforced or implied; there is no real meaning of the words "table" or "column". To a key-value store all it knows about is a big collection of bytes you pass to it - the "value" - and a smaller collection of bytes - the "key" - used to index that big collection. What is inside that big collection and how it maps onto byte in other values in the database is entirely down to your application and the quality of the code in it.

Other NoSQL DBMSs, however, do allow you to define what is inside the "value". They hold a schema for the data, much like relational databases do. Cassandra is an example of this.

So it is up to you and how you implement your application. You could set up your key-value store to mimic a relational data model with surrogate ids. This would require a lot of reads and lose the point of a NoSQL solution. You could set up your key-values to store all denormalised values at the instant the record was written. This will be fast for retrieval but slow for updates. You have to choose what's best for your system and implement it accordingly. NoSQL is not magic. You still have a lot of design and development to do.

The term NoSQL is very broad. It has more to do with marketing than with a technology. Still less to do with maths such as the set theory underpinning relational databases. Different NoSQL products work differently. You will not know all of "NoSQL" by reading just Parse.com.

Understand your problem. Understand the compromises you are prepared to make to achieve your performance or consistency goals and choose the product which best matches your requirement.