Hey guys good morning, I’ve a scenario here, not s...
# help
t
Hey guys good morning, I’ve a scenario here, not sure if it’s actually a common one or not on dynamodb (nosql dbs) so here I go: If I’ve tables for inventory items (let’s say cars), invoices and companies, do I need to create one
this.table_{something} = new Table(
for each table in dynamodb? Is that how it should work or would you do everything in one table? (if so, then how?) Note: I’m aware I can “nest” data for example:
car.invoices = []
and have the invoices there, but for the companies (makers), if I want to pull them dynamically from a table then it makes me some noise
s
So, this is an SST and DynamoDB question 🙂
The easy part first: The sst Table construct is for a single DynamoDB table. If you have multiple DynamoDB tables, you'll need multiple SST Table constructs
The harder question: DynamoDB has a concept of single table design. Although controversial in some circles, it's largely considered a best practice when working with DynamoDB. The concept is that you use a single table to support a variety of access patterns in your application (e.g. fetch overdue invoices for user, fetch inventory by company, etc) by storing multiple entity types in the same table. The single table paradigm is meant to eliminate the expensive join operations of the RDBS solutions by storing your related data together in a single table.
The paradigm can be challenging to learn if you're coming from a RDBMS background, so it can have a steep learning curve. There are completely valid uses of multiple DyanmoDB tables, so it's not a "one size fits all" suggestion to use single table design. However, it's a widely adopted approach to successfully using DynamoDB and should probably be your default starting point
If you want to get on the fast track for what all this means, watch

this 40 minute video from AlexDebrie from the 2019 AWS Re:Invent conference

. Alex is the author of The DynamoDB Book, which is the best resource for learning DynamoDB if you want to go deeper.
t
@Seth Geoghegan thank you for your detailed answer, yes in fact I come from relational DBs so it’s kinda noisy “non-acceptable) on top of my head, but I want to change that and adopt more nosql/dynamodb things for sure. That said, I think I need to take a break on development/building and read about dynamodb practices before continuing building the app. I’ll move forward with that book as suggested for sure. Thank you very much!
a
👍 to everything Seth said. I’d also highly recommend Rick Houlihan’s talk:

https://www.youtube.com/watch?v=HaEPXoXVf2k

It gets a bit advanced at the end, but the first section nicely builds up the case for DynamoDB.
r
And The DynamoDB Book by Alex DeBrie will walk you through how to think about one table design with practical approaches to one-to-many and many-to-many requirements. One thing I would say is don't force unrelated entities into a single table. I asked Rick Houlihan about this on twitter and he agreed it complicated things unnecessarily
s
Also, today is Ricks last day at AWS! I saw he's going to MongoDB 🤯
g
Yeah mongo db is going serverless.. they have launched: • atlas serverless instances - same princing model as dynamo and fully manage services • Data api - no more tpc connection. HTTP api to talk to mongo... equals to dynamo.. I think it will be great for serverless as mongo can do aggregation pipelines..
r
He's a NoSQL junkie
s
Yeah, super interested to learn more about NoSQL from the Mongo perspective.
j
Yeah we’ve been working with the MongoDB team, should have something published about their serverless offering soon.
t
@Seth Geoghegan @Akos ty for these, I went through both videos (very clear and helpful) + also the DynamoDBBook (I don’t finish it yet) so I’ve a better idea now about “how to noSQL on DynamoDB”!