In today’s world of Big Data, everyone is looking for efficient ways to store data that supports building high-level analytics. Here come the NoSQL databases into existence.
When it comes to database designing, most of the people who migrate from SQL to NoSQL databases find it difficult to effectively design their database, because NoSQL databases as compared to SQL databases are less strict in terms of constraints and data types.
1. Forget SQL database before designing NoSQL database
Yes, you read it right. Before designing the NoSQL database, you need to completely forget the SQL database methodologies like normalization, data types constraints, primary key, foreign key etc, because NoSQL database has its own methodologies.
NoSQL databases work on the indexes, very similar to the primary key concept of SQL databases. But it’s not very strict to define the index. For example, MongoDB by default creates an index on the _id field generated automatically when you insert data into the collection (Collection is similar to TABLE in SQL DB).
2. Modeling Relationships
When designing a NoSQL database schema, you need to start with a question: what is the cardinality of the relationship? Put less formally: you need to characterize your “One-to-N” relationship with a bit more nuance: is it “one-to-few”, “one-to-many”, or “one-to-squillions”? Depending on which one it is, you’d use a different format to model the relationship.
Here I have explained in brief about the first two One-to-N relationships.
a) One-to-Few
An example of “one-to-few” might be addressed for a person. This is a good use case for embedding.
> db.person.findOne()
{
name: ‘John Dew’ ,
addresses : [
{ street: '123 Sesame St', city: 'Anytown', cc: 'USA' },
{ street: '123 Avenue Q', city: 'New York', cc: 'USA' }
]
}b) One-to-many
An example of “one-to-many” might be parts for a product in Product Management System. Each part would have its own document or separate table and product have its own document. One can reference multiple parts of a product like below.
> db.products.findOne()
{
name : ‘‘Maruti Suzuki',
manufacturer : 'Maruti',
parts : [ // array of references to Part documents
ObjectID(‘123'),
ObjectID('234'),
ObjectID('345'),
]
}Each part defined in the array is separate document in other collection. There can be other ways to model the one-to-many relationship. But you can think of this as one of the simplest way to implement. In this way, you can even define many-to-many schema, as you can use same part in other products as well.
So based on the cardinality of your relationship, you can choose to implement any of the One-to-N schema designs.
1. Embed the object into parent object, if there is no need to access the embedded object outside of the parent object and the relationship cardinality is one-to-few.
2. Use an array of references if there is need to access the embedded object as a stand-alone entity and the relationship cardinality is one-to-many.
For large scale applications where we have One-to-N or N-to-N relationship, we can implement the schema designs accordingly.
Note: Here MongoDB is taken as reference for NoSQL database. One can compare the advantages and disadvantages of other NoSQL Databases and choose appropriately that suits your requirement.