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

Question

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

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

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

Конечно, у сотового телефона есть другие атрибуты, чем у планшетных ПК, а у ноутбука есть и другие атрибуты, такие как RAM, CPU, размер дисплея и так далее.

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

Что я хочу понять, так это то, что каждая «категория» имеет схему, и когда один из пользователей системы вводит новый продукт (скажем, новый 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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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