При работе с DynamoDB и денормализации в попытке преобразовать реляционные данные в образ мышления NoSql
Я хотел бы понять подход денормализации в конкретном случае.Как только это будет иметь смысл для меня, я почти уверен, что откроется шлюза знаний.
Давайте предположим, что у меня есть база данных (RDMS) для песен, и у меня есть жанры.Я, вероятно, сделал бы что-то вроде этого
generas
|generaId | generaTitle|
|5| Rock & Roll|
|6| Hip Hop|
песни
titleid| generaId | title
321|5| Great Balls of Fire
322|6| Gimme Some More
Я бы присоединился к этим таблицам, чтобы получить generaTitle, и я мог бы легко обновить родыЗаголовок, просто обновив одну запись
UPDATE generas set generaTitle = 'Rock n Roll' where generaId = 5;
В DynamoDB
titleid '65as56ldjalskd23131sdad'
title: Great Balls of Fire
genre: Rock & Roll
Итак, давайте предположим, что у меня теперь есть 100 000 названий песен в рок-н-ролле.Разве мне не нужно было бы выполнять масштабное обновление 100 000 записей, чтобы просто изменить это?
-OR-
Нормально ли иметь некоторые программные отношения, чтобы я мог сделать это
titleid '65as56ldjalskd23131sdad'
title: Great Balls of Fire
genre: 5
На уровне приложения я знаю, что 5 = Рок-н-ролл из предыдущего запроса и кэшировал его.
Я могу обернуть голову вокруг вторичных индексов и глобальных вторичных индексов с точки зрения запроса.
Кажется, что все еще должен быть какой-то уровень отношений.Я могу согласиться на то, что 100 000 раз «Rock & Roll» будет повторяться снова и снова, но я не могу согласиться с концепцией обновления 100 000 записей для замены Rock & Roll на Rock N Roll
Как будто все разговоры и публикации говорятвокруг этого, и я думаю, что это, пожалуй, одна из самых больших проблем для нас, ребят из RDMS.Может быть, это только я.
Теперь, если кто-то сказал мне: "у вас нет отношений уровня базы данных в NoSQL, но это очень нормально, если не предполагается, что у вас будут таблицы, которые вы используете для отношений уровня приложения", весь моймир изменится.
Если это не так, может кто-нибудь объяснить мне это.