Skip to content

Data Model

Jump to bottom
Sergey Sorokumov edited this page Nov 2, 2022 · 18 revisions

Описание назначений коллекций, типов данных и сущностей

Графическое представление

Untitled

Коллекция Users связана с коллекцией Orders через поля first_name second_name fathers_name
Коллекция Autopark связана с коллекцией Orders через поля number brand model

Подробное описание

БД содержит 3 коллекции:

  1. Autopark
  • _id - уникальный идентификатор автомобиля
  • number - гос. номер автомобиля
  • brand - название марки авто
  • model - название модели авто
  • free - свободна ли машина
  • ready - готова ли машина к работе
  • vin - VIN номер автомобиля
  1. Users
  • _id - уникальный идентификатор пользователя
  • first_name - Имя
  • second_name - Фамилия
  • fathers_name - Отчество
  • login - логин, для входа
  • password - пароль для входа
  • timetable - Рассписание работы (если пользователь -- работник)
  • role - Тип пользователя
  1. Orders
  • _id - уникальный идетификатор пользователя
  • sender_info - информация о отправителе
    • first_name - Имя
    • second_name - Фамилия
    • fathers-name - Отчество
  • recipient_info - информация о получателе
    • first_name - Имя
    • second_name - Фамилия
    • fathers-name - Отчество
  • size - размеры посылки
    • height - высота посылки
    • width - ширина посылки
    • length - длина посылки
    • weight - вес посылки
  • address - адрес доставки
  • paid - оплачена ли доставка
  • expected_date - ожидаемая дата доставки
  • real_date - реальная дата доставки
  • courier_info - информация о курьере
    • first_name - Имя
    • second_name - Фамилия
    • fathers-name - Отчество
    • car_info - информация об автомобиле, если доставка большого груза
      • number - гос. номер автомобиля
      • brand - название марки авто
      • model - название модели авто
  • complete - выполнен ли заказ
  • cost - стоимость заказа

Оценка удельного объема информации, хранимой в моделе

  1. Autopark
  • _id - int64 - 8b
  • number - str (9 символов) - 9b
  • brand - str - max 15b
  • model - str - max 15b
  • vin - str (17 символов) - 17b
  • free - bool - 1b
  • ready - bool - 1b Один элемент занимает 66b
  1. Users
  • _id - уникальный идентификатор пользователя
  • first_name - str - max 35b
  • second_name - str - max 35b
  • fathers-name - str - max 35b
  • login - str - max 35b
  • password - str - max 35b
  • timetable - list(list(str, str)) - max 100b
  • role - char - 1b Один элемент занимает 276b
  1. Orders
  • _id - int64 - 8b
  • sender_info - list[str, str, str] - 105b
  • recipient_info - list[str, str, str] - 105b
  • size - list[int64, int64, int64, int64] - 32b
  • address - str - 100b
  • paid - bool - 1b
  • expected_date - date - 4b
  • real_date - date - 4b
  • courier_info - list[str, str, str, list[str, str, str]] - 144b
  • complete - bool - 1b
  • cost - int64 - 8b

Один элемент занимает 512b

Пример модели

Моделирование компании с 30 автомобилями, 50 сотрудниками, 1000 пользователей и 50000 заказов - 25791780 ~ 25,8Mb


Выразим объем модели через количество заказов, на каждый заказ приходится по 3 пользователя, на каждый второй заказ приходится 1 автомобиль, тогда получим линейную зависимость равную $$V_d(m)=512m + m/3(276) + m/2(66) = 637m$$

Избыточность модели равна: $$V_d(m)= \frac{512m + m/3(276) + m/2(66)}{158m+m/3(276) + m/2(66)} = \frac{637m}{283m} = \frac{637}{283} = 2.25$$

Запросы

  • Поиск пользователя при авторизации
db.users.findOne({login:login, password: password})
  • Поиск всех свободных машин, готовых к работе
db.autopark.find({ready: true, free: true})
  • Поиск заказов с опозданием
db.order.find({$where: function(){
   return obj.expected_date != obj.real_date}})
  • Поиск расписания работника
db.users.findOne({_id: courier_id})['timetable']
  • Поиск всех выполненных заказов
db.order.find({complete: True})
  • Поиск всех заказов, выполненных определенным работником
courier = db.users.findOne({_id: id})
db.order.find({courier_info: [courier...], complete: True})
  • Поиск определенного заказа
db.order.find({_id: id})

Аналогичная реляционная модель

Графическое представление

image

Подробное описание

  1. Autopark
  • _id - уникальный идентификатор автомобиля - int64 - 8b
  • number - гос. номер автомобиля - varchar (9 символов) - 9b
  • brand - название марки авто - varchar (15 символов) - 15b
  • model - название модели авто - varchar (15 символов) - 15b
  • vin - VIN номер автомобиля - varchar (17 символов) - 17b
  • ready - готова ли машина - bool - 1b
  • free - свободна ли машина - bool - 1b Один элемент занимает 66b
  1. Users
  • _id - уникальный идентификатор пользователя - int64 - 8b
  • first_name - Имя - varchar (35 символов) - 35b
  • second_name - Фамилия - varchar (35 символов) - 35b
  • fathers-name - Отчество - varchar (35 символов) - 35b
  • login - логин, для входа - varchar (35 символов) - 35b
  • password - пароль для входа - varchar (35 символов) - 35b
  • type - Тип пользователя - char - 1b
  • Один элемент занимает 184b
  1. Timetable
  • _id - уникальный идентификатор расписания - int64 - 8b
  • day - день недели - varchar (2 символов) - 2b
  • time - время работы - varchar (11 символов) - 11b
  • user - идентификатор пользователя, кому принадлежит расписание - int64, 8b Один элемент занимает 29b
  1. Order
  • _id - уникальный идентификатор заказа - int64 - 8b
  • sender_info - уникальный идентификатор отправителя - int64 - 8b
  • recipient_info - уникальный идентификатор получателя - int64 - 8b
  • height - высота посылки - int64 - 8b
  • width - ширина посылки - int64 - 8b
  • length - длина посылки - int64 - 8b
  • weight - вес посылки - int64 - 8b
  • address - адрес доставки - varchar - 100b
  • paid - оплачена ли доставка - bool - 1b
  • expected_date - ожидаемая дата доставки - date - 4b
  • real_date - реальная дата доставки - date - 4b
  • courier_info - информация о курьере - int64 - 8b
  • complete - выполнен ли заказ - bool - 1b
  • cost - стоимость заказа - int64 - 8b Один элемент занимает 182b

Моделирование компании с 30 автомобилями, 50 сотрудниками (по 5 записей в расписании), 1000 пользователей и 50000 заказов - 9302430 ~ 9.3Mb

SQL Запросы

  • Поиск пользователя при авторизации
SELECT * FROM Users WHERE login = login  AND password = password;
  • Поиск всех свободных машин, готовых к работе
SELECT * FROM Autopark WHERE ready = true AND free = true;
  • Поиск заказов с опозданием
SELECT * FROM Order WHERE expected_date != real_date;
  • Поиск расписания работника
SELECT * FROM Timetable WHERE user = id;
  • Поиск всех выполненных заказов
SELECT * FROM Order WHERE complete = true;
  • Поиск всех заказов, выполненных определенным работником
SELECT * FROM Order WHERE complete = true AND courier_info = id;
  • Поиск определенного заказа
SELECT * FROM Order WHERE _id = id;

Сравнение моделей

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

Clone this wiki locally