Мне нужно спроектировать модель данных для приложения, подобного Amazon S3. Давайте упростим задачу в 3 ключевых понятиях - пользователи, корзины и объекты. Есть много способов создать эту модель - я перечислю два.
Три вида - Пользователь, Ведро и Объект. Каждый объект имеет Bucket в качестве родителя. Каждый Bucket имеет пользователя в качестве родителя. Пользователь - root.
Динамические виды - пользователи хранятся в виде пользователя, а сегменты - в виде корзины - так же, как # 1. Однако объекты внутри корзины хранятся в динамическом виде с именем " _Object". Больше нет родительских / дочерних отношений между объектами bucket и object. Эта связь устанавливается по названию вида объекта.
# 1, конечно, более интуитивная и традиционная модель. Можно утверждать, что № 2 является радикальным, в то время как другие могут сказать, что смешно.
Почему я думаю о # 2? - В моем приложении свойства, определенные для объектов, могут варьироваться от корзины к корзине. Эти свойства указываются пользователем во время создания корзины. Кроме того, все свойства объектов должны быть доступны для запроса. Динамический тип объекта для каждой группы позволяет мне поддерживать эти требования. Более того, поскольку мой вид объекта теперь является корневым, мне больше не нужно применять фильтры предков, что означает, что я получаю индекс для каждого свойства объекта бесплатно. В модели № 1 я вынужден применять фильтры предков, что означает, что мне нужен собственный индекс для каждого свойства, к которому я хочу выполнить запрос.
Я прошу прощения за запутанное объяснение. Попробую лучше, если не понятно.
Мои вопросы - это # 2 совершенно возмутительная модель? С # 2 мои виды потенциально могут столкнуться с десятками тысяч. Это нормально? Я понимаю, что существует ограничение на количество пользовательских индексов. Но я не создаю пользовательские индексы для своих динамических типов, а только полагаюсь на автоматические индексы.
Спасибо,
Keyur