hello, thank you for sharing this video, i have a question about GSI3. the sort key is the property_id, i was expecting to see "property" again as we're requesting all properties. while scaning do we know the property_id?
I'm confused. Do we end with one table or two? I ask because it's possible to have 1 composite key with multiple indicies (GSI & LSI) on a single table but you can't have multiple composite keys on a single table in dynamo like we seem to have at the end of this video.
What a brilliant video! Probably the only video that walk thru a design phase! Love it! So much to learn. With this series, I am very confident I will complete my app with DynamoDB! Much thanks!
I watching two times for understand this is the best series for start the modeling help me to undertand many things in the end all is so clear thnx so much for this series from mexico.
Nice video ! I ended up close to your final thoughts. 4 access patterns solved by the table and 3 by GSI. Regarding the table I prefer to have a sort key with value #info or booking#bookginId to be able to fetch info of a property or all its bookings. For GSI location I prefer to have country as PK and city as SK to be able to fetch all property of a country. For GSI userId I ended up with a SK propertyID but I prefer yours with the starting date to be able to sort with a date. For GSI ownerId I perfer to have the SK the same as the table to have the info and bookings straight forward. I tried the dynamoDB workbench. It's very useful. Don't hesitate if you want to compare with my model. Thanks again for all your videos !
Based on this one-table model, after a USER signs up for an account, I assume we have all the user's information like user_id, address, city, phon_number Etc. We can locate a user using the GSI. I get that. But we must have values for the table's primary key and sort key. What do we use? The user account has no property_number or booking_date because those records aren't yet related to properties in any way. Also, how do you put the string "property" in a date field? Isn't that field of type, number (i.e, unix timestamp)?
Great video thanks for sharing, I am new to DynamoDB and find it very useful, the only part I found confusing is when you mentioned that you are using only one table, I thought you had at the end two different tables because they have different Primary Keys, does it mean that DynamoDB can have more than one primary key definition in a single table?
Simply brilliant - apart from proper modeling, biggest benefit of this VDO is discussion on "pros and cons" of each decision - plz keep posting such use cases. You have awesome thought process and presentation skill.
@@foobar_codes si, por favor... es que quiero entender bien el uso de DynamoDB y tus videos me han servido mucho... he estado revisando mucho pero tus videos estan bien explicados... y traducirlo con youtube es patetico.. no se entiende nada
@@foobar_codes Thank you so much for quick response, got a question. So the attribute we define for a DynamoDB should be a key schema or GSI/LSI? So what should we do if there are more number of attributes which we dont want to be part of keyschema or GSI/LSI?
Really interesting, but as usual, sometimes we do not have all the requirements access at the beginning of the project. The PO could come later with another access, such as : Ok now, we need to get properties available between two dates. How do you handle this when it could "break" your first access patterns ?
You have probably already solved this, but you can add a global secondary index if your app allows for downtime, otherwise if you need a local secondary index or can't have downtime you would have to copy your table into a new table with your new index added in the setup process
@@jesse9999999 we added a GSI indeed, but it was complicate because initially, the value was in a nested attributes. As we can't create a GSI based on nested property, we had to duplicate the information at the root. Not really pretty.
