Лучший способ представления многоязычной базы данных по MongoDB

Question

У меня есть базы данных MySQL для поддержки многоязычного веб-сайта, где данные представлены в следующем виде:

table1

id 
is_active 
created 

table1_lang

table1_id 
name 
surname 
address 

Каков наилучший способ добиться этого в базе данных mongo?

Answer 1

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

// db.table1 schema 
{ 
    "_id": 3, // table1_id 
    "is_active": true, 
    "created": ISODate("2015-04-07T16:00:30.798Z"), 
    "lang": [ 
     { 
      "name": "foo", 
      "surname": "bar", 
      "address": "xxx" 
     }, 
     { 
      "name": "abc", 
      "surname": "def", 
      "address": "xyz" 
     } 
    ] 
} 

В примере схеме выше, вы бы по существу внедренный table1_lang информации внутри основного table1 документа. Этот проект имеет свои достоинства, одним из которых является локальность данных. Так как MongoDB хранит данные на диске, то все необходимые вам данные в одном документе гарантируют, что на вращающиеся диски потребуется меньше времени для поиска в определенном месте на диске. Если ваше приложение часто обращается к table1 информации вместе с данными table1_lang, вы почти наверняка захотите пойти по встроенному маршруту. Другим преимуществом встроенных документов является атомарность и изоляция в письменных данных. Чтобы проиллюстрировать это, что вы хотите удалить документ, который имеет ключевое «имя» языков со значением «Foo», это может быть сделано с помощью одного (атомном) операций:

db.table.remove({"lang.name": "foo"}); 

Для получения более подробной информации о моделировании данных в MongoDB, пожалуйста, прочитайте документацию Data Modeling Introduction, в частности Model One-to-Many Relationships with Embedded Documents

другой вариант дизайна ссылается документы, где следуют нормированную схемы. Например:

// db.table1 schema 
{ 
    "_id": 3 
    "is_active": true 
    "created": ISODate("2015-04-07T16:00:30.798Z") 
} 

// db.table1_lang schema 
/* 
1 
*/ 
{ 
    "_id": 1,  
    "table1_id": 3, 
    "name": "foo", 
    "surname": "bar", 
    "address": "xxx" 
} 
/* 
2 
*/ 
{ 
    "_id": 2,  
    "table1_id": 3, 
    "name": "abc", 
    "surname": "def", 
    "address": "xyz" 
} 

Приведенный выше подход обеспечивает большую гибкость при выполнении запросов. Например, чтобы получить все дочерние table1_lang документов для основного родительского объекта table1 с идентификатором 3 будут просто, просто создайте запрос к коллекции table1_lang:

db.table1_lang.find({"table1_id": 3}); 

приведенной выше нормированной схема с использованием документом ссылочного подхода также имеет преимущество когда у вас есть отношения «один ко многим» с очень непредсказуемой ясностью. Если у вас есть сотни или тысячи table_lang документов на каждый объект table, вложение имеет так много неудач в отношении пространственных ограничений, поскольку чем больше документ, тем больше оперативной памяти он использует, а документы MongoDB имеют жесткий размер 16 МБ.

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

Ref:

MongoDB Applied Design Patterns: Practical Use Cases with the Leading NoSQL Database By Rick Copeland