top of page

DynamoDB Data Structure vs Traditional SQL Server

Rebecca Boardman

I've been starting to look at DynamoDB as a person that comes from a MS SQL relational Database background DynamoDB introduces some new concepts which are quite different so to be honest it's taken me a while to get my head round even the most basic core ideology with it! I'm not a big fan of complex technical jargon - and reading up online about this was quite frankly making my head hurt - so I figured.. if I could make a blog post to explain in a clear and concise way then it's probably a great idea- i'm by no means an expert but it's great to try look into something and break it down into a more digestible piece of information- that way it might sink in more!


To get started I wanted to show the differences in a visual representation to how data may look in a traditional relational database like SQL Server vs how a table may look in DynamoDB. While we are looking into DynamoDB we'll break down some of the basic concepts of a DynamoDB table.


To get started say we have a Database called BookLibrary. As part of this database we like to keep a record of authors and books. So this is what you'll see from a traditional SQL relational database point of view


Author

This details the name of the author and their date of birth


Book:

This includes the ISBN (international standard book number) which can be used to uniquely identify each book, the authorID and the title of the book.


Because this is a relational database, you'll notice that the above books table will have Authorid as a foreign key which allows us to join the two tables together. Say we wanted to return any book titles where the author was born after 01/01/1946 we'd be able to join these two tables together


select name, DOB, Title
from author as auth
inner join book as b
on auth.authorid = b.authorid
where [DOB] > '01/01/1946'

Dynamo DB

DynamoDB is a serverless NOSQL Database service which was created and provided by Amazon. It's suitable for document and key-value store models. Because DynamoDB uses NOSQL It's built to scale with high performance. DynamoDB has an extremely flexible data model. DynamoDB operates it's capacity in terms of RCU (Read Capacity Units) and WCU (Write Capacity Units).


Tables- DynamoDB stores it's data in tables. Sound familiar to SQL Server? Think Again!

As Per the example Above you'll notice SQL Server Stores each individual entity eg (books, authors) into different tables and then allows you to join these two tables with the use of foreign keys. Whereas with DynamoDB you can put these entities into one single table even though some of the attributes (values) might be completely different (this bit made my head hurt).




Item- an item belongs to a table, items are essentially a group if attributes. This would be a unique identifiable attribute or a set of attributes which together would uniquely identify an item.

A primary key can be used in order to uniquely identify each attribute. This is either a single attribute known as a partition key or a composite primary key which is a combination of two attributes (partition key and sort key).


Attribute- These are data elements of an item. These would contain specific data information- eg columns (Name, DOB etc)


So if we take the previous example into account instead of having data in two tables we could keep them all into one table called booklibrary.


This table could look a little something like this:


*I've highlighted so you can see where the above would fit in as an example:


You'll notice that now, both the author information and book details can be detailed in the same table. In this case in the BookLibrary table we use a composite primary key because we know one author can have many books therefore by using a primary key of (Author # xxxx) and a sort Key of (ISBN#XXXX) which will uniquely identify each item by the Author Name and international standard book number. We then have a list of different attributes eg: DOB, Name, Type etc.


Conclusion

There you have it, a visual example to how the data structure from a DynamoDB table may differ from a traditional RDBMS eg SQL Server. Hopefully the above made sense, I'm really no expert when it comes to Dynamo but i'm planning to blog more and more as I learn- hopefully these blogs can be a great reference point for you and will prevent you from getting lost down the rabbit hole of so much complex information. As always thanks for reading.

Recent Posts

See All

Comments


bottom of page