DynamoDB Relationships - 4 Many to Many

Поделиться
HTML-код
  • Опубликовано: 29 сен 2024

Комментарии • 22

  • @Fonsecaj89
    @Fonsecaj89 3 месяца назад

    Its always better to use SQL for relationship...

  • @arturofm
    @arturofm 3 года назад

    I think the naming of the SK (the items) is very confusing, what if I have todo list 1 and I want to add different tags to it

  • @lukeclimbs
    @lukeclimbs 7 месяцев назад

    I know this video is old so I may not get a response but just in case:
    Following the example in this video.
    Let's say I have two UI pages.
    (User Page) One for a user which shows the users profile as well as a list of what teams they are a part of.
    (Team Page) One for a team which shows some team metadata as well as what users are members of the team.
    On both of these I'd like to be able to display some basic information about the "many" items of the relationship. For example on the user page, each team shown should at least have the teams name and for the Team page each member of the team should show some basic information about that user such as their first name, last name and maybe their role.
    My confusion lies in the fact that the metadata I'm looking to display isn't necessarily part of the teamMember item but instead part of the original user profile or team meta item.
    Thinking about the Team Page, I wouldn't want to have to make 1 query in order to see the teamMembers and then another query for each teamMember to retrieve the actual profile data of that given team member.
    In that case would you want to duplicate the users profile data onto the teamMember item?
    If that is what you want to do, if the users name is mutable, do you then have to go and update all teamMember items with the new name when the users profile changes?
    Sorry for the long winded question. I'm just starting to try to fully wrap my head around complex many-many relationships in single table design.

    • @sleepwalkergt
      @sleepwalkergt 6 месяцев назад +1

      That's right. You'll have to first get interested items. Then using batch request - get extended details about related items you need. There is no better way to do it, but this one is not bad itself. The number of requests is for sure not the only metric to look at.
      Highly recommend to check "The DynamoDB" book. It describes such concepts in details

  • @hungdinh99
    @hungdinh99 2 года назад +1

    Hi @Gary Jennings, How can I get both meta data of team and users in fetching users by team id query ?

  • @tahasaleh4697
    @tahasaleh4697 4 года назад +3

    I think the "teamMemberXXXX" as a Sort Key is redundant in this case. Creating a GSI with SK as its PK would have worked perfectly to achieve the many-to-many relationship.

    • @woolytech6465
      @woolytech6465 3 года назад

      A GSI with SK as its PK would not be able to handle the "Team has many Tasks" relation as the GSI created in video.

  • @Qornv
    @Qornv 3 года назад +1

    Thanks, really makes you think about storage differently compared to RDB

  • @zagamendes2438
    @zagamendes2438 Год назад

    Why didn’t you just add a new row/item with pk=user_1234 and sk=team_1234?

  • @ppgg997
    @ppgg997 2 года назад

    The only video that made me understand what's going on! But it isn't possible to get also the user's name and address in a single query (like the last one) right?

  • @giulioambrogi5413
    @giulioambrogi5413 2 года назад

    If you were to "list all team members for team X by first name", how can you do that?

  • @omphemetsemafoko830
    @omphemetsemafoko830 4 года назад +1

    Thank you for the scenario explanation.

  • @ericxcn
    @ericxcn 2 года назад +1

    Hey man, thanks for making these videos, this has been extremely helpful!

    • @GaryJennings
      @GaryJennings  2 года назад

      Thanks Anderson

    • @GaryJennings
      @GaryJennings  2 года назад

      Single table design stands the test of time, I’ve used it on every project I’ve worked on since 2018, it’s pretty versatile

  • @jitender167
    @jitender167 3 года назад

    Gary jennings Great tutorial. could you please share the code also

  • @rodpadev
    @rodpadev 3 года назад

    Great explanation! This is so straight forward with examples, thank you a lot

  • @cutebijou13
    @cutebijou13 3 года назад

    Super useful! Thanks for also giving an example

  • @torrija76
    @torrija76 4 года назад

    looks like the sort key 'teamMember_xxxx' could just be 'teamMember' because the '_xxxx' part is not used in this scenario.

    • @frederikstergaard4510
      @frederikstergaard4510 4 года назад +1

      I believe the combination of PK and SK must be unique, therefore some unique value must be concatenated onto the SK

    • @ChrisShenton
      @ChrisShenton 4 года назад

      It's not clear what the suffix of teamMember_* is, does 1234 refer to a team number, or a member (user) number; using different suffixes would make this more clear.

    • @GaryJennings
      @GaryJennings  4 года назад +4

      Its not a team or member, this item represents a relationship between a team and a member. 1234 would be a generated uuid in a real app. You can think of it as ${entity}_${randomId}, and together they make up one single id. The reason why we have a word at the beginning instead of just a uuid is so we can query 'give me all items where the SK starts with 'teamMember' that belong to a team, which is the same as saying, give me all team members belonging to this team. If they were just uuids without the 'teamMember' text at the beginning, you would not be able to do a beginswith query.