Как хранить реляционные POCO в мире nosql? - PullRequest
0 голосов
/ 20 декабря 2010

Мы работаем над проектом, который имеет реляционную объектную модель, и мы хотели бы использовать решение no / sql (couchdb) для некоторой части хранилища данных. Например, есть пользователи и приложения, которые связаны друг с другом через поле «UserId Applications» (или свойство «User» в мире DDD)

Как правильно хранить пользовательские данные в couchdb в документе «Приложение»? С идентификатором для связи или поместить весь объект «пользователь» в документ «приложения»? Если я помещу весь объект «пользователь» в документ приложения, обновление пользователя приведет к обновлению всех документов приложения, в которых содержится вся информация о пользователе.

Мы немного сбиты с толку, поэтому я буду очень рад услышать некоторые идеи по этому поводу.

Спасибо.

1 Ответ

0 голосов
/ 20 декабря 2010

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

Тем не менее, пользователь почти всегда имеет смысл как отдельный объект. Однако вы не ограничены использованием только идентификатора пользователя в документе приложения - включая отображаемое имя (которое редко изменяется), вероятно, устраняет почти столько же чтений, сколько и весь объект пользователя.

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