Как осуществить поиск в Mongo по ключу и значению по всему документу?

Question

[Artem Taranoff]

Добрый день.
Необходимо найти всех людей которые окончили, например, институт 567.
Проблема в том, что мы не можем точно указать родительские элементы для этого института(и находятся на разных уровнях).
Например и в professions.actor.theatre.drama и в professions.actor.stuntman есть institute

{
    "_id": ObjectId("56ff619b14989a0ed0316921"),
    "firstName": "Иван",
    "lastName": "Лабанов",
    "professions": {
        "actor": {
            "film": {
                "drama": {
                    "institute": 567
                },
            },
            "theatre": {
                "drama": {
                    "institute": 123,
                },
            },
            "stuntman": {
                "institute": 321,
            }
        },
    }
}, {
    "_id": ObjectId("56fe77b114989a05577e9f22"),
    "firstName": "Петр",
    "lastName": "Смирнов",
    "professions": {
        "actor": {
            "film": {
                "comedy": {
                    "institute": 567,
                }
            },
        }
    }
}, {
    "_id": ObjectId("56fe77b114989a05577e9f11"),
    "firstName": "Василий",
    "lastName": "Иванов",
    "professions": {
        "actor": {
            "film": {
                "comedy": {
                    "institute": 123,
                }
            },
        }
    }
}

Answer 1

[KkJ]

Никак.
У вас странная структура БД.
Это че - один и тот же человек учился на театрального комедийного актера и на киношного комедийного актера?

Comments

[Artem Taranoff]

Да, такая ситуация возможна(и такое бывает не редко), когда человек получает две разных профессии.
Благо сейчас структура только проектируется, и если возможно, не могли бы предложить более правильную структуру для такой ситуации?

[KkJ]

Artem Taranoff: Ситуация, когда человек учился в нескольких уч. заведениях - вполне возможна, да.
Но.
Зачем вы вкладываете уч. заведение в специализацию, а затем в профессию?
В Mongo есть массивы. Это самый подходящий инструмент для хранения информации об образовании.
Массив - "где учился". А в этом массиве назначение учебного заведения и профессия.

[Artem Taranoff]

KkJ: я правильно понял, что вы предлагаете, например, в корне документа хранить данные так:
"institute": [
{
"name": "ВГИК",
"faculty": "Режиссерский факультет",
"department": "Кафедра телевидения",
"year": 2010
}
]

[KkJ]

Artem Taranoff:
Примерно.
Я бы не стал называть этот institute, а назвал бы более общим словом, так как образование может быть и курсами и пр., а не только ВУЗом.

[Artem Taranoff]

KkJ: да, конечно, это я как пример привел.
Спасибо за ответ!

Answer 2

[Андрей]

вот что бывает, когда реляционные данные пытаются в нереляционную бесструктурную базу впихнуть...
реляционка легко решает эту задачу.

Comments

[Artem Taranoff]

Не совсем. Мы как раз таки выбрали не реляционную именно потому, что у нас данные хоть и структурируются, но они имеют вложенность, с которой прекрасно справляется монга.
Суть задачи - у нас множество людей творческих профессий(и еже с ними): Актёры, Озвучка, Модели, Мейкаперы. У каждой из этих профессий есть множество направлений (актёр театра, актёр кино, цирковые актёры, каскадеры), у этих направлений могут быть конкретные специализации (театр оперы и балета, актёр комедийного кино и тд), и так еще несколько уровней вложенности(образование, знание языков и тд). Сложность не просто в хранении, а в том, чтобы можно было искать по этим параметрам.
Вот реальный пример запроса:
Мужчина, выше 180см, до 25 лет, водительские права категории С, окончивший ВГИК, солист оперы(итальянский язык), умеющий жонглировать.

[KkJ]

Монга прекрасно решает эту задачу.
Данные - не реляционные.

[KkJ]

Artem Taranoff: "умеющий жонглировать", "умеющий глотать огонь" - это просто список навыков. хранить в списке (массиве). зачем вы столь глубокую вложенность сделали - непонятно совсем.

[Андрей]

Artem Taranoff: ну и отлично это все ложится в реляционные таблицы..

[Андрей]

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

[Artem Taranoff]

Андрей: не могли бы предложить структуру?
Мы думали уже разные варианты, и например, EAV модель не подходит, и вертикальная key-value таблица, конечно же тоже.

[Андрей]

Artem Taranoff: универы / мероприятия - обычная m2m связь через третью таблицу.

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

[sivoyanope]

Андрей:
> а теперь представьте, если ВУЗ по такой структуре переименуется....

Неважно, что он переименовывается сейчас.
На момент когда этот человек учился - ВУЗ назывался именно так как он назывался тогда.

Если человек родился в Ленинграде, то в паспорте так и записано.
И при выдаче нового паспорта ему же не будет написано Санкт-Петербург, в новом паспорте тоже будет написан Ленинград.

Хотя его дети, родившиеся в этом же городе, уже будут иметь в документах место рождения Санкт-Петербург, а не Ленинград.

[KkJ]

sivoyanope:
Андрей:
> на счет нереляционности данных не соглашусь

Ну да, ваша реляционность притянута за уши.
Товарищ прекрасно на примере Ленинграда все рассказал.

[Андрей]

KkJ: реляционность данных сам автор признает, собираясь там ID шники хранить.
И потом, вот есть люди.
Есть учебные заведения.
Если специальности.
Вполне обычные, по жизни реляционные, данные...

Люди -> m2m -> Программы Подготовки,

Программа Подготовки -> Специальность
Программа Подготовки -> Учебное заведение.

[KkJ]

Андрей:
И РСУБД и Монгой прекрасно можно решить эту задачу.
Мало ли чего там автор признает. Он не хрена не авторитет - уж очень бредовую структуру предлагает.

Из-за таких зашоренных как вы в БД много чего не предусматривают, например, невозможно ввести двойные имена (Мария-Магдалина Ивановна Петрова) или очень длинные фамилии.

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

[Андрей]

KkJ: какое вообще отношение двойные имена с длинными фамилиями имеют к выбору субд?

Если ВУЗ переименовался - то не вижу проблемы.

В монге да, реализовать тоже можно. Только поиск по всем этим программам будет тем еще счастьем.

[KkJ]

Андрей:
Ты увидел реляционно-подобные данные и положил их на реляционную БД совершенно не думая о возможных сценариях работы.

ВУЗ переименовался - не видь проблемы. Но в твоей структуре это будет означать автоматическое появление кучи ложных данных.

Вот такие "умные" и пишут потом БД, которые учитывают только часть сценариев.

Поиск там - равноценный. Ты в пылу спора уже совсем стал факты подтасовывать.

[Андрей]

KkJ: ок, хочешь ты сохранить старое название - да фигня вопрос, добавить еще вуз и вузу же old_id, есть и другие способы.

А на счет части сценариев - есть тз, в котором и есть сценарии.

Хотите под знаменем "зато без джойнов" избыточно хранить данные или писать монструозный map/reduce - да флаг вам в руки.