Концепция: правильно ли монго применять схемы?

Question

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

Не вдаваясь в подробности, я попытаюсь объяснить, что делает приложение.

Приложение просто имеет "сущности".Эти объекты - технические вещи, такие как мобильные телефоны, телевизоры, ноутбуки, планшеты и т. Д.

Конечно, у мобильного телефона есть другие атрибуты, чем у планшетных ПК, а у ноутбука есть даже другие атрибуты, такие как ОЗУ, Процессор, размер дисплея и т. Д.

Теперь я хочу иметь что-то, что мы хотим назвать схемой: мы определяем, что нам нужно сохранить размер дисплея, количество оперативной памяти флэш-устройств, тип процессора, процессор и тд для планшета шт.Для мобильного телефона мы можем сохранить размер дисплея, GSM, Edge, 3g, 4g, процессор, оперативную память, технологию сенсорного экрана, бла-бла-бла.Я думаю, вы поняли:)

Я хочу понять, что у каждой «категории» есть схема, и когда один из пользователей системы вводит новый продукт (скажем, новый iphone 4), приложениесоздает форму, которую необходимо заполнить соответствующими атрибутами.

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

Атрибут, смоделированный в монго, выглядит так:

{
_id: 1234456, name: "Attribute name", type: 0, "description"
}

Но что делать, если мне нужен этот атрибутна нескольких языках, например:

{
en: {name: "Attribute name", type: 0, "description"},
de: {name: "Name des Attributs, type: 0, "Beschreibung"}
}

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

Есть идеи на этот счет?

Answer 1

Вы можете решить эту проблему несколькими способами.

Вы можете иметь массив языковых переводов, встроенных в документ атрибута:

{
    _id: 1234, 
    type: 0,
    somethingElse : "foobar",
    translation: [
        "en" : { name: "Attribute name", description : "Description" }
        "de" : { name: "Name des Attributs", description: "Beschreibung" }
    ]
}

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

Или вы также можете использовать свою модель и обновить несколько атрибутов одним обновлением.

Все зависит от ваших предпочтений.

Answer 2

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

Преимущество MongoDB по сравнению с реляционной базой данных заключается в возможности расширять вашу схему с течением времени по мере изменения ваших потребностей. С точки зрения производительности, может быть полезна возможность отправлять обновления в базу данных без круговой обработки всего документа (используя $ set или $ push или другую функцию обновления), а возможность гибкой индексации в различных составных полях может сделать запросы быстрыми. .

Если я понимаю ваш вариант использования, общий объем данных будет относительно небольшим (несколько тысяч документов, каждый не более нескольких КБ) и поэтому будет помещаться в ОЗУ в скромной системе и поэтому будет быстрым. Но вы будете писать логику на стороне клиента, чтобы навязать желаемую структуру и отношения.

Answer 3

Документ в базе данных Монго может иметь любые или все свои атрибуты, обновленные в одном операторе update. Триггеров нет - если вы хотите, чтобы документ обновлялся при изменении атрибута типа, вам нужно сделать это в логике приложения.