Метеор Модель данных в Монго

Question

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

У меня есть работающая система, которая построенная из MongoDB, NodeJS и угловые ,

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

{ 
    _id: ObjectId('123'), 
    name: "Project A", 
    components: [ 
    { 
     compType: "type-A" 
    }, 
    { 
     compType: "type-B" 
    } 
    ] 
} 

Теперь я Meteor для оценивая на стороне сервера базы и после играя с ним какое-то время, читая документацию и глядя на примеры, я вижу, что даже в простом примере Todos вместо моделирования данных в виде списка, содержащего todos в нем, он моделируется как два отдельных коллекций.

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

Неужели я не прав об этом чувстве? Что произойдет, если я смогу приложение Todos с одной коллекцией lists и просто получить обновление, когда новый элемент будет добавлен в список, а не обновление о конкретном элементе?

Answer 1

afaik DDP может синхронизировать поддокументы и изменения отдельных клавиш. Приложение todos, вероятно, использовало две различные коллекции по другим причинам, кроме оптимизации для DDP. Если вы действительно хотите понять, как работает DDP, читайте больше об этом и смотрите трафик websocket в инспекторе. Это не должно занять много времени, чтобы сравнить два подхода к моделированию todos.