NOSQL Database Design | NOSQL Basic Modeling

NOSQL Database Design | NOSQL Basic Modeling

This Modeling applies to almost all "Document Based Store" NOSQL
Modeling usually contains ONE to ONE , ONE to MANY or MANY to ONE relationships.

ONE to ONE

One good example might be a person entity having only one address.

If you think about a person entity,It would include Person Id  "ID" primary key, Name , one  Address etc.
Here we have embedded address in the person document itself and persisted as one single document.

Person
{
  id : '112121',
  name: 'Kate Monster',
  ssn: '123-456-7890',
  address :  { street: '123 Sesame St', city: 'Anytown', cc: 'USA' }
  
}

ONE to MANY

Lets take a same person where one person can have more than one address which defines ONE to MANY relationship.

Person
{
  id : '112121',
  name: 'Kate Monster',
  ssn: '123-456-7890',
  address :  [
    { street: '123 Sesame St', city: 'Anytown', cc: 'USA' }
    { street: '123 Avenue Q', city: 'New York', cc: 'USA' }
 ]
}

This embedding design has its own advantages and disadvantages , Advantage is that you don't have to perform a separate query to get the embedded details, Disadvantage is that you have no way of accessing the embedded details as stand-alone entities.

 For example : If you want  "Addresses" of all Person, It is not possible to get them independent of Person entity. First you need to access Person document then extract address from it.


This can be overcome by concept called "Reference" as show in the documents  below

Address Documents
{_id : ObjectID('AAAA'), street: '123 Govind St', city: 'Anytown', cc: 'UK' }

{_id : ObjectID('F17C'), street: '456 Yo St', city: 'Anytown', cc: 'USA' }

{_id : ObjectID('D2AA'), street: '789 notown St', city: 'Anytown', cc: 'PAK' }


Person
{
  id : '112121',
  name: 'Kate Monster',
  ssn: '123-456-7890',
  address :  [
     ObjectID('AAAA'),    
        ObjectID('F17C'),   
        ObjectID('D2AA'),
 ]
}

Here the addresses must be saved first  OR address must have its own ID to link them in Person document.

Each Person document will contain an array of ObjectID that refers to the Address Entity.

You would then use an application-level join to retrieve the Address for a particular Person, This style of referencing has a complementary set of advantages and disadvantages to embedding.

Each Address is a stand-alone document, so it's easy to search them and update them independently.

One trade off for using this schema is having to perform a second query to get details about the Address for a Person.