Блог

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

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

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

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

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

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

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

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

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

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

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