Схема схемы MongoDB

Question

1. Может ли схема диаграммы mongodb на диаграмме классов (формат UML) быть осуществимой, поскольку диаграммы ER больше связаны с SQL.

2. При представлении идентификатор в схеме высокого уровня, который из следующих 3 имеет правильный тип: (Int или ObjectId или _id)

   id: int 
   

   ИЛИ

   id: bson.ObjectId 
   

   ИЛИ

   id: _id 
   

3. При представлении объекта поддокумента в схеме схемы, whi ч следующего 2 имеет правильный тип (String или Object)

   comments : String [ 
           { 
            userName : String 
            date : String 
            actualComment : String 
           } 
           ] 
   

   ИЛИ

   comments : Object [ 
           { 
            userName : String 
            date : String 
            actualComment : String 
           } 
           ] 
   

---

UPDATE

Если я следующий поддокумент (здесь является представлением JSON), как Монго хранит ответы - какой бы он был?

comments : String [ 
         { 
          userName : String 
          date : String 
          actualComment : String 
          replies : comment [ ] // how does mongo store nested replies 
         } 
         ] 

Answer 1

1. осуществимый, но не подходит во всех случаях. FK relationships can be represented the same way. For arrays, embedded, etc. you'd have to establish a representation/interpretation.
2. ObjectID - тип; это BSON type. _id - название поля. Не знаю, как получилось за int, типы BSON - 32-битное целое число и 64-битное целое число.
3. Ни один из них. Это просто (суб) документ.

---

UPDATE

Это массив технически. Нет конкретного типа. В этом случае вы, вероятно, думали о массиве из объектов комментариев, но могли бы быть все, что вы хотите, я думаю (включая поддокументы).

Answer 2

Диаграмма классов UML предназначена для классов в объектно-ориентированном программировании, а диаграмма ER предназначена для отношений в реляционной базе данных. MongoDB не является ни объектной базой данных, ни реляционной базой данных, поэтому ни один инструмент действительно не подходит для MongoDB. Но, учитывая только эти два инструмента, я предпочел бы использовать диаграммы классов UML, потому что ER подчеркивает то, чего лучше всего избегать в MongoDB: отношения между документами.

По умолчанию поле _id заполнено сгенерированным значением типа BSON ObjectId, поэтому ваш второй пример bson.ObjectId будет технически корректным, если вы используете значение по умолчанию. Однако у вас нет , чтобы использовать значение по умолчанию.. Вы также можете явно указать свои поля _id на собственное значение любого типа, который вы хотите.Поэтому, если вы по какой-то причине хотите использовать целые числа для ObjectId (помните, что вам нужно позаботиться о том, чтобы они были уникальными), вы можете, конечно, сделать это и сказать это в своей документации. Если вы не используете пользовательские значения для своих _id, а в противном случае не используете их, вы можете просто опустить их из своих диаграмм, потому что они подразумеваются.

На мой взгляд, встроенные документы лучше всего выражаются в диаграммах классов UML, используя композицию (стрелка черного алмаза), в то время как ссылочные документы выражаются с помощью агрегации (стрелка белого алмаза). Поддокумент определенно не является String. Object лучше, но даже лучше было бы использовать правильный тип.

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