Дизайн схемы Mongodb подходит для одного предложения

Привет, я новичок в mongodb. Я использую java.

У меня есть система с двумя таблицами, system_properties в моей реляционной таблице.

Что-то вроде этого.

       Table              Fields                                        values

      System           System_ID(PK), System_Info                  100, cisc
                                                                   200, Gets
      System_prop      System_ID(FK), Prop_key, Description        100, good, success
                                                                   100, better,progress  
                                                                   200, worse,failed

Я пытаюсь создать для этого схему. например: для вставки одного документа

      System
         {
             "_id" : 100
             "System_Info" : "cisc"
             System_Properties :
                 { "system_id":100
                        [{prop_Key : "good", Description: "success"}, 
                         {prop_Key : "better", Description: "progress"}] }
         }

Это лучшая схема для такого дизайна?

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

Я сомневаюсь, необходим ли system_id: 100 (внешний ключ в реляционных таблицах), поскольку "_id" = 100 (primarykey в реляционной таблице) также относится.


mongodb mongodb-query mongodb-java schema-design
person Ramya    schedule 05.09.2012    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Передний ключ в вашем объекте свойств не нужен, так как вы встроили их в документ. Системные свойства должны быть просто массивом или даже объектом, например:

{
     "good": "success",
     "better": "progress"
}
person Konstantin Pribluda    schedule 05.09.2012

arrow_upward
1
arrow_downward

Есть несколько способов спроектировать эту схему, даже используя две коллекции. Так:

Как ваше приложение использует сохраненную информацию?

Есть ли у вас неограниченный рост этих встроенных свойств? => плохая идея!

Есть ли такие, у которых всего два свойства, некоторые со 100, а некоторые с 1 тыс.? => старайтесь придерживаться одного размера документов в коллекции. (используйте ведение, и если вы хотите, чтобы для вашего основного документа были отмечены избранные / лучшие 5)

Дополнительная информация: Обсуждение схемотехники Элиота Горовица

person Marc    schedule 05.09.2012

arrow_upward
0
arrow_downward

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

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

person Louisa    schedule 05.09.2012
comment
manning.com/banker (MongoDB в действии) 10gen.com/presentations/mongosf2011/schemabasics 10gen.com/presentations/mongosv-2011/schema-design-by-example 10gen.com/presentations/mongosf2011/schemascale А вот несколько образцов схем: docs.mongodb.org/manual/use-cases - person Louisa; 05.09.2012