Разработка схемы Dynamodb (отображение реляционных данных в nosql) - PullRequest
Новая
       26

Разработка схемы Dynamodb (отображение реляционных данных в nosql)

0 голосов
/ 07 февраля 2019

Попытка разобраться в этом примере из AWS для сопоставления реляционной модели с nosql

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-modeling-nosql-B.html

Выделена ключевая концепция:

Важно

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

Учитывая, что пример таблицы выглядит следующим образом

dynamodb table

Объясняется,

Вы определяете следующие объекты, которые поддерживают схему ввода реляционных заказов:

HR-сотрудник - PK: EmployeeID, SK: Имя сотрудника

HR-Region - PK: RegionID,SK: Имя региона

...

Однако, объект HR-Employee - PK: EmployeeID, SK: Employee Name в таблице примера имеет SK значений, которые не являются Employee Name с.

Также предлагается следующий запрос

enter image description here

, но GSI-1 не имеет PK Employee Name.

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

Может ли кто-нибудь направить меня в правильном направлении с точки зрения отсутствияsql схема сопоставления?Правильный пример (с примерами записей таблицы динамо) для схемы в приведенной выше ссылке будет очень полезен.

1 Ответ

0 голосов
/ 08 февраля 2019

Итак, я постараюсь сделать это более понятным для вас, дайте мне знать, если что-то все еще не имеет смысла.

Для начала, вы упомянули тот факт, что:

Однако объект HR-Employee - PK: EmployeeID, SK: имя сотрудника в таблице примера содержит значения SK, которые не являются именами сотрудников.

Причина, по которой значения SK не являются "Employee"«Имена» - это потому, что SK не только для «Имена сотрудников», но и для других запросов (таких как «Имя региона», «Название страны» и т. Д.).Думайте о СК как о том, что именно он обозначает, как ключ к сортировке.Кажется, в документации не хватает объяснения дополнительных SK, которые у них есть, поэтому позвольте мне обобщить то, на что вы смотрите.

У вас есть HR-Employee1 с Employee Name = Employee1, QuotaID (угадывает, что это за ключ) = QUOTA-2017-Q1, некоторый другой ключ = HR-CONFIDENTIAL

Эти имена ключей на самом деле не определены в таблице, все они идут под ключом сортировки и являются неявно «именем сотрудника» или ««идентификатор квоты» или «имя региона».

Это позволяет вам запрашивать данные о сотрудниках, используя employeeID в качестве PK и имя сотрудника в качестве SK, но также позволяет запрашивать данные Quota сотрудника (или что-либо подобное).это так), используя employeeID в качестве PK и quotaID в качестве SK.

То же самое относится и ко второму вопросу, касающемуся GSI-1.По сути, способ, которым они разработали таблицу в этом сценарии, заключается в том, что у вас есть SK "SortKey", где вы можете иметь различные типы значений для сортировки, если это имеет смысл.

...