Hello Fellow Developers!

This article will point you in the direction of how one must think while developing a No-SQL Data Model. Here the No-SQL database that I am referring to will be AWS DynamoDB. So let's begin!

You would first need to read the AWS DynamoDB Official Documentation to understand the working of AWS DynamoDB. It is very essential to understand the Overview, Features, Pricing and the Use-cases of AWS DynamoDB.

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html

Thereby, I will be writing this blog with the assumption that you have read the AWS Official Documentation thoroughly. docs.aws.amazon.com/amazondynamodb/latest/d..

Sign in to your AWS Account and access AWS DynamoDB, create a table, fill in data. By now, you must have realized how data is structured and stored in AWS DynamoDB. The most important part is the key-value pair, and that is the only thing you need to worry about throughout this process of defining the data model.

Preliminary inspection of the interface is necessary to observe the required entities, which are "Table", "Items" and "Attributes", you need to pace yourself to get your hands on the schema design tool, there are mainly two reasons to adhere to this step religiously, firstly designing an ERD gives a clear picture of how many "Tables" are required, what all "Items" are going to be grouped by which all "Attributes". In simple words, Entity Relationship Diagram gives you the space to form a relationship between data that you plan to store for your project.

The tool that I use for schema design is "Hackolade". It is honestly an amazing product to design and visualize schema for No-SQL databases.

hackolade.com

Once you have access to Hackolade, sit down and roughly structure your data in tables, form relationships, this may take a lot of iterations, A LOT. I am not even kidding!

My data model started with 10 Tables, now in Version 7 of revamping the data model, all the data relationships are managed in a single-table design. I know this seems impossible, but I have done it and so can you. AWS DynamoDB provides an amazing level of flexibility and scalability.

Here the most important part is your Partition Key [Primary Key + Sort Key], I am not going to go into the technicalities of this because AWS Official Documentation would be the right place to get all the information from but I want to highlight this sentence in case you have missed "As long as the Primary Key, or the Partition Key is unique in AWS DynamoDB, you can fit in data without the need to have separate tables for different functionalities"

Now, it's your job to declare them uniquely, and let AWS DynamoDB handle the rest.

I will be publishing more content on how numerous relationships can be stored in single-table or 'How to go about "Single-Table Design" which is the whole essence of using AWS DynamoDB or for that matter any No-SQL database.

Now that, you are at the stage of getting used to the working of No-SQL, which is actually important that no one stresses about, there are different ways you can create the table and see the actual storage of data in the structure that you have finalized.

This is the final part includes either running the Hackolade generated Scripts through AWS CLI, or using SDK's or directly making tables from the console, whichever way you choose, understand how each gels in with your overall architecture.

Also, no one tells you this and I learned in a hard way, the importance of LSI and GSI's. Local and Global Secondary Indexes gives you the scope to use other attributes as Partition Key's which is why single-table design is no more a DREAM.

As and when the data is pushed under that particular attribute in AWS DynamoDB, the visibility of those attribute names would come into the picture. Before that, Do Not Expect to even exist there. The attributes that get committed without data in AWS DynamoDB are all the Primary Keys and Sort Keys whether it's declared for the main table or those declared for LSI's & GSI's.

I am sure, after reading this article your venture to explore AWS DynamoDB would be more systematic and less panicky.

Nevertheless, this blog did not mean to state technical facts, as you can easily access it from anywhere but these steps will help you to begin with AWS DynamoDB and fall in love with it.

I am a huge fan of Alex DeBrie, the author of "The DynamoDB Book", his book explains and has every scope covered related to AWS DynamoDB. Referring to his book would give you clarity and deeper insights regarding AWS DynamoDB

If you can't get his book, this would be useful

dynamodbguide.com/what-is-dynamo-db

Lastly, watch a lot of AWS re: Invents videos while you work through the above-mentioned steps, AWS is not only known for their awesome cloud architecture but also the way they document their services and deliver them to the audience. I am linking a few here for your reference

youtube.com/watch?v=DIQVJqiSUkE

youtube.com/watch?v=fiP2e-g-r4g

youtube.com/watch?v=iN6mhI5hFt4

youtube.com/watch?v=TCnmtSY2dFM

youtube.com/watch?v=yvBR71D0nAQ

youtube.com/watch?v=6yqfmXiZTlM

A video of Rick Houlihan keeps all worries at bay, his explanation for "Advanced Design Patterns for DynamoDB" is my favorite!

youtube.com/watch?v=HaEPXoXVf2k

Lastly, I would also mention Marcia Villalba (youtube.com/channel/UCSLIvjWJwLRQze9Pn4cectQ), she has some informative videos about AWS DynamoDB which honestly helped me to gain a better perspective about AWS DynamoDB.

youtube.com/watch?v=Tb8Cw3TUDRM

That is enough content to begin exploring AWS DynamoDB for starters, I would be posting detailed explanations of how different data relationships can co-exist together where-in I would be covering more technical details to thereby achieve a single table design in AW DynamoDB.

Ending this blog with an inspiring quote "You can never understand everything. But, you should push yourself to understand the system" -Ryan Dahl