Блог

Я новичок в DynamoDB и пытаюсь создать дизайн DynamoDB, чтобы представить приведенное ниже отношение:

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

Однако проблема в том, что, когда я хочу знать, есть ли у пользователя 1 контент 3, мне нужно сделать два запроса. Есть ли лучшая стратегия для обработки этого в одном запросе?

Несколько заметок:

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

чтобы предотвратить несколько запросов, вам также нужно будет поместить контент № 3 под пользователем № 1, например, атрибут»SK: CONTENTCOLLECTION#2 «#КОНТЕНТ#3».

конечно, это становится очень невеселым очень быстро. Многие ко многим-это отношения, которые не очень легко воспроизвести в «Динамо». Это также может привести к большему количеству записей, но в целом это нормально, потому что запись, как правило, дешевле/быстрее, чем чтение в большинстве ситуаций (эмпирическое правило: 2 записи в порядке, 2 чтения — нет, что вы, похоже, уже получили)

Дело в том, что ваши данные разработаны в первом решении для хранения — то есть вы решили, что лучше иметь один тип объекта пользователя, один тип контента и одну коллекцию контента. Все это прекрасно и отлично подходит для общих ситуаций — и было бы прекрасно для базы данных SQL, но в тот момент, когда вы пытаетесь навязать ей единый шаблон доступа, он разваливается.

Это вдвойне подтверждается началом вашего вопроса: вы хотите создать динамический шаблон, соответствующий этому шаблону взаимосвязи данных. Вместо этого вы должны спросить: у меня будет эта информация, и я хочу иметь возможность получить эти данные — Как мне разработать схему динамо-машины, чтобы облегчить это?

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

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