DynamoDB - Как «сломать» иерархию без использования отношений?

Question

Рассмотрим следующее представление JSON DynamoDB для программного обеспечения для управления проектами.

Application = {
  "Users" : [
    "user1" : {"name" : "john"},
    "user2" : {"name" : "jack"}
  ]
  "Projects" : [
    "project1" : {
      "users" : [
        "user1",
        "user2"
      ]
    }
  ]
}

В проекте может быть много пользователей, а у пользователя может быть много проектов.

В Projects> project1> users рекомендуется использовать ключ пользователя / id? Я вижу, что я симулирую традиционные отношения и не использую DynamoDB правильно.

Я прочитал руководство о взаимоотношениях «многие ко многим» здесь , но, честно говоря, я просто не могу понять их визуальную схему или объяснения.

Answer 1

Это сложная тема, и я не мог бы объяснить все это в этом ответе, но я могу указать вам на некоторые превосходные ресурсы, которые должны предоставить вам ответы, когда они подробно рассматривают эту тему.

Видео: AWS re: Invent 2018: глубокое погружение Amazon DynamoDB - я предлагаю посмотреть все это, чтобы полностью понять концепцию, но вы можете перейти к 45:42, чтобы перейти прямо кчасть о формировании иерархических данных.

Answer 2

Если вы используете базу данных для представления отношений, например, между пользователями и проектами, особенно если у вас много-много связей, вы можете вместо этого использовать базу данных Graph, такую ​​как AWS Neptune.По общему признанию, базы данных Graph могут показаться немного пугающими и теоретическими для начала.

Вы правы, что в DynamoDB вы будете использовать ID пользователя в таблице проектов, а затем искать в таблице Users, чтобы получить пользователейдля данного проекта.Причина, по которой кажется, что это не использует DynamoDB правильно, состоит в том, что DynamoDB по сути является только хранилищем значений ключей.Допустимые значения могут быть довольно сложными, но вы не можете изначально моделировать какие-либо отношения между ключами.

DynamoDB теперь поддерживает транзакции, поэтому вы можете при необходимости запросить несколько таблиц в одной атомарной транзакции.

Если вы обнаружите, что у вас много подобных отношений, вам следует рассмотреть использование реляционного или графическоговместо базы данных.