Разработка схемы базы данных документов

Question

Я тщетно пытаюсь научиться использовать объектные базы данных. В учебниках по базам данных традиция, кажется, использует пример отслеживания учащихся, курсов и классов, потому что это настолько знакомо и применимо. Как этот пример будет выглядеть как объектная база данных? Реляционная база данных будет выглядеть примерно так:

Student
  ID
  Name
  Address

Course
  ID
  Name
  PassingGrade

Class
  ID
  CourseID
  Name
  StartTime

StudentClass
  ID
  ClassID
  StudentID
  Grade

Будете ли вы хранить StudentClasses внутри Classes, которая, в свою очередь, находится внутри Course, а затем сохранять Student в качестве объекта высшего уровня?

Student
  ID
  Name
  Address

Course
  ID
  Name
  Classes[]
    Name
    StartTime
    Students[]
      StudentID

Answer 1

Итак, у вас есть Course s, Student s и Class es, которые являются частями Course s и посещены Student s? Я думаю, что вопрос отвечает сам, если вы думаете об этом. Возможно, будет понятнее, если вы отойдете от чистого JSON MongoDB и посмотрите, как бы вы определили его в ODM (эквивалент ORM в RDB), поскольку БД на основе документов на самом деле не применяют свои собственные схемы (пример основан на на MongoEngine для Python):

class Student(Document):
    name = StringField(max_length=50)
    address = StringField()

class Attendance(EmbeddedDocument):
    student = ReferenceField(Student)
    grade = IntField(min_value=0, max_value=100)

class Class(EmbeddedDocument):
    name = StringField(max_length=100)
    start_time = DateTimeField()
    attendance_list = ListField(EmbeddedDocumentField(Attendance))

class Course(Document):
    name = StringField(max_length=100)
    classes = ListField(EmbeddedDocumentField(Class))

Это даст вам две коллекции: одну для Student с и одну для Course с. Attendance будет встроен в Class es, а Class будет встроен в Course s. Примерно так (псевдокод):

Student = {
    name: String,
    address: String
}

Course = {
    name: String,
    classes: {
        name: String,
        start_time: DateTime,
        attendance_list: {
            student: Student,
            grade: Integer
        }[]
    }[]
 }

Конечно, вы можете поместить информацию об оценке в объекте учащегося, но в конечном счете вы действительно мало что можете сделать, чтобы избавиться от этого дополнительного класса.

Answer 2

Посмотрите на DatabaseAnswers , чтобы узнать, есть ли у них существующая схема, отвечающая вашим потребностям.

Answer 3

Весь смысл OODBMS состоит в том, чтобы позволить вам проектировать вашу модель данных, как если бы она была просто в памяти. Не думайте об этом как о проблеме схемы базы данных, думайте об этом как о проблеме моделирования данных, исходя из предположения, что у вас много ВМ и ограниченный объем физической памяти. Вы хотите убедиться, что у вас нет вскипятить множество сбоев страниц (или, фактически, операций ввода-вывода в базе данных) для выполнения важных операций.

Answer 4

В чистом OODB ваша модель в порядке.