Нереляционная структура базы данных путаница - PullRequest
0 голосов
/ 28 января 2020

Я изучаю MongoDB и пытаюсь осмыслить идею не использовать схему реляционной базы данных.

Для моего приложения я хочу иметь возможность добавлять новых пользователей и проекты и назначать пользователей в проекты с помощью Роли, например, «менеджер», «разработчик» и т. Д. c. Пользователи должны иметь возможность просматривать подробную информацию о проектах, в которых они имеют роль. Получение сведений о проекте должно включать список пользователей, также имеющих роли в этом проекте.

Предположим, что я добавляю нового пользователя через POST в /users. Я могу добавить новый проект с POST к /projects.

Затем я хочу дать пользователю роль в проекте. Я мог бы сделать PUT для /users/{id} с ролью (включая имя роли и идентификатор проекта), но тогда получение сведений о проекте через GET /projects/{id} не будет включать список пользователей с ролями в этом проекте.

Я мог бы вместо этого POSTed Роли /project/{id} (включая имя роли и идентификатор пользователя), но тогда GET /users/{id} не будет включать их роли, и я мог бы хотеть отобразить роли, в которых участвует пользователь, на их целевая страница.

Для создания новой роли мне действительно нужно было бы установить PUT на /users/{id}, а затем сделать еще один PUT на /projects/{id} с ролью и пользователем?

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

Я что-то здесь упускаю? Любые советы или полезные ссылки будут с благодарностью.

Ответы [ 2 ]

0 голосов
/ 28 января 2020

Вы правы. У баз данных NO Sql есть концепция, которая не является проблемой, если вы повторяете одни и те же данные вдоль «таблиц», поскольку эта повторяющаяся информация имеет код ha sh, который идентифицирует данные, которые вы будете использовать при Вы хотите обновить его.

0 голосов
/ 28 января 2020

Боюсь, вы достигли большого недостатка в базах данных NO SQL, когда исходили из реляционных. Ответ заключается в том, чтобы забыть все, что вы знаете о нормализации, и дублировать данные в обоих местах, а затем поддерживать их в актуальном состоянии.

Я знаю, что это противоречит всему, чему вас научат в базе данных SQL но это один из компромиссов. Роб Волк сделал хорошую статью по этому поводу здесь https://robvolk.com/nosql-design-patterns-for-relational-data-9c2c11ae3b4a

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

...