MongoDB Вложенная философия дизайна

Question

Я создаю систему, в которой у компании есть несколько пользователей, клиентов и т. Д. Я не могу решить, делать ли «Объекты», например пользователей, отдельную коллекцию или встроенные документы документа компании.

Company (Object) ->
    Users (Object) ->
        Profile (Object) ->
            ...attrs..
        History (Object) ->
            ...attrs...
    Customers ->
        ...attrs...

Я застрял в мышлении реляционной базы данных прямо сейчас, и не уверен, что "правильный" способ сделать это с NoSQL. Что ты думаешь?

Что происходит, когда двойной внедренный документ (например, компания> пользователи-> история) становится смехотворно большим?

Каковы некоторые другие минусы подхода встроенного документа (если есть)? Опять же, я склонен к реляционному мышлению.

Заранее спасибо.

Answer 1

http://www.mongodb.org/display/DOCS/Schema+Design дает несколько советов по дизайну схемы, также есть несколько презентаций членов 10Gen, таких как: http://dl.dropbox.com/u/205597/sts/sts-04-2012-mongo-and-nosql-schema.pdf

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

Answer 2

Если вам не нужно запрашивать и получать статистику и т. Д. По соответствующим данным, сделайте их встроенными, что также ускоряет запросы.Если вам необходимо извлечь эти данные для какой-либо цели, создайте для них новую коллекцию (ы).

Answer 3

Я могу дать здесь несколько общих советов, но, в конце концов, вам решать, какой подход вы выберете.Вопрос, который вам нужно задать, чтобы определить, нужно ли встраивать или ссылаться на него:

Какие данные вам нужно вернуть при получении документа для большинства запросов?

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

Естественно, если ваш набор данных и возвращаемые значения не так однозначны, то он становитсяболее сложный вопрос.

Если поле требуется часто, но не все оно необходимо (скажем, последние 5 записей в истории), сохраните их фиксированного размера в основном документе и оставьте остальные в отдельной коллекции.Это вызывает некоторые дубликаты и усложняет ваши обновления, но может быть хорошим компромиссом с точки зрения скорости.

С точки зрения минусов - большой встроенный документ сам по себе неплохой, но растущий, особенно с неограниченнымрост может быть плохим.Каждый раз, когда документ увеличивается, есть вероятность, что он будет слишком большим для выделенного ему пространства, что означает, что его придется перемещать.Мало того, что это несколько фрагментирует ваши данные, это может быть дорогой операцией для перемещения большого документа, выделения нового пространства - особенно если вы делаете это часто.Документы по коэффициенту заполнения объясняют это довольно хорошо (коэффициент заполнения добавляется при запуске хода):

http://www.mongodb.org/display/DOCS/Padding+Factor#PaddingFactor-Overview

Надеюсь, это поможет!