Как мы проектируем Динамо БД с сохранением отношения двух лиц - PullRequest
3 голосов
/ 27 февраля 2012

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

У меня есть следующие таблицы 1) пользователи - user_id, имя пользователя, пароль, адрес электронной почты, номер телефона, роль 2) роли - идентификатор, имя [то есть администратор, руководитель, т. Д.]

a) Мое первое сомнение в том, что у нас есть какое-либо условие для установки автоматического приращения для полей user_id? б) Это правильный способ установки первичного ключа как user_id? в) Это правильный метод для хранения роли пользователя в динамо-базе данных? то есть таблица ролей содержит идентификатор и заголовок и хранить идентификатор роли в пользовательской таблице? e) Можно ли получить данные двух таблиц вместе с каждым пользователем? Использую рельсы 3 и aws-sdk gem

Если кто-нибудь ответит, это будет очень полезно для меня, как нового пользователя DynamodB

Ответы [ 2 ]

6 голосов
/ 27 февраля 2012

Как правило, в базах данных в стиле nosql вы предоставляете уникальный идентификатор, а не поле PK с автоматическим приращением, которое делает это за вас.Обычно это означает, что для каждой записи пользователя будет использоваться GUID.

Что касается пользовательских ролей, существует множество способов сделать это, и у каждого есть свои преимущества и проблемы:

Одним простым способом было бы добавить атрибут «Роль» в таблицу «Пользователи» и иметь одну запись для каждой роли для этого пользователя.Тогда вы можете получить пользователя и получить все роли в одном запросе.DynamoDB позволяет атрибутам иметь несколько значений, поэтому один атрибут может иметь одно значение для каждой роли.

Если вам нужно иметь возможность запрашивать пользователей в определенной роли (например, «Дайте мне всех пользователей, которые являются супервизорами»)) тогда вы будете выполнять сканирование таблицы в DynamoDB, что может быть дорогостоящей операцией.Но если количество пользователей достаточно мало и необходимость такого поиска нечаста, это все же может быть приемлемо для вашего приложения.

Если вам действительно нужен такой дорогой поискчасто вам нужно будет создать новую таблицу, например, «RolesWithUsers», имеющую одну запись на роль, с именами пользователей в записи роли.Для большинства приложений я бы посоветовал не делать что-то подобное, потому что теперь у вас есть две таблицы, отражающие один факт: какую роль играет конкретный пользователь.Таким образом, удаление или обновление необходимо выполнять в двух местах каждый раз.Это невозможно сделать, но требуется больше бдительности и тестирования, чтобы убедиться, что ваше приложение не получает неправильные данные.Другим недостатком этого подхода является то, что вам нужны два запроса для получения информации, которые могут быть более дорогими, чем сканирование таблицы, опять же, в зависимости от количества записей.

Еще один вариант, который имеет смысл для этого конкретноговариант использования будет использовать SimpleDb.У него лучшая возможность запросов (все атрибуты индексируются по умолчанию), и в этом случае единственная таблица с ролями в качестве многозначного атрибута будет гораздо лучшим решением, чем DynamoDB.

Надеюсь, это поможет!

0 голосов
/ 29 мая 2015

У нас похожая ситуация, и мы просто используем две БД: реляционную и NoSQL (Dynamo).Для объекта «Пользователь» все, что связано с другими вещами, например ролями, проектами, навыками и т. Д., Относится к реляционным, а все, что касается пользователя (атрибуты и т. Д.), Отправляется в «Динамо».Если нам нужно добавить новые атрибуты для пользователя, это нормально, поскольку NoSQL не заботится об этих атрибутах.Эмпирическое правило: если нам нужно что-то только на этой объектной странице (то есть нам не нужно связываться с другими объектами), тогда мы помещаем в «Динамо».В противном случае все идет по реляционному принципу.

Использование сканирования таблицы в БД NoSQL на самом деле не вариант, даже если вы пересекаете даже небольшой порог (до этого момента вы все равно можете просто использовать БД в памяти).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...