DocumentDB не имеет схемы , я бы сказал, что возможность вставлять документы с любой схемой и иметь индексы, которые не заботятся о «типе» документа в одной и той же коллекции, в значительной степени преднамеренная. Бессмысленно бороться с этим.
Конструкция позволяет вам иметь столько (или несколько) коллекций, сколько вы считаете наиболее подходящими для нужд производительности / обслуживания / организации данных. Вы можете легко начать с одной коллекции и перенести N типов в другую, если считаете, что дополнительные расходы оправданы. Так что вы МОЖЕТЕ создать «набор коллекций, которые представляют логическую модель данных» , если вы готовы платить за предоставленные дополнительные RU - наличие единого пула, из которого можно обрабатывать пики, обычно дешевле, чем N меньших Таким образом, для того, чтобы быть в безопасности, нужно делить сверхобеспечение еще больше. Но это твой выбор.
Об индексах - если вам нужно хранить 2 объекта с одинаковыми именами свойств, проектирует вашу модель так, чтобы они имели различный путь и, следовательно, могли различаться в запросах и индексах. ИТ также имеет смысл для мышления реляционных БД: не храните разные факты в одном и том же поле данных. Технически вы могли бы сделать это, но обычно это скоро откусывается.
Наличие родительского контейнера с разными именами для каждого «типа» - это самый простой и довольно перспективный способ дифференциации типов, поскольку он позволяет добавлять или передавать «типы» между коллекциями и по-прежнему избегать конфликта индексов. С другой стороны, убедитесь, что поля «перекрестного типа» хранятся в едином месте для унифицированных индексов, например, полей аудита или глобально уникальных ключей.
Как всегда, дизайн данных диктует, что вы можете или не можете делать.