Ваш подход будет зависеть от того, как часто вы предвидите, что люди настраивают шаблон, а не просто переходят на стандарт. Как насчет гибридного подхода?
То есть, есть поле в пользовательском документе, которое создается лениво (при использовании), в котором либо хранится пользовательский шаблон, либо, возможно, отличается от одного из стандартов (не уверен насчет уровня настройки, который вы планируете разрешить). ).
Тогда вы можете получить поле шаблона, которое вы описали в пункте 2 выше, со «специальной» настройкой для пользовательских шаблонов. Несмотря на то, что вы по-прежнему беспокоитесь о том, чтобы извлекать шаблон каждый раз, у вас есть преимущество в том, что вы знаете, что это некоторые из ваших более преданных пользователей - сохранение поездки в БД может быть выгодным, или вам может быть все равно.
Если вам не нужны 2 поездки в БД для каждого пользователя, тогда вы выбираете подход 2, добавляете пользовательские шаблоны в коллекцию шаблонов и просто ссылаетесь на новый идентификатор для каждого настраиваемого пользователя.
Это уравновешивающее действие - это дополнительные издержки данных с точки зрения извлечения шаблона каждый раз, когда стоит сохранить поездку в оба конца в БД, или вы хотите повысить эффективность с точки зрения данных, которые вы получаете каждый раз за счет нескольких запросов к БД - только вы можете ответить на этот вопрос в зависимости от того, как вы разрабатываете свое приложение и как его используют люди.
Для связанного подхода вы можете взглянуть на Ссылки на базу данных и Схема в документации MongoDB.