Есть ли лучший дизайн в mongodb для создания системы пакет / кошелек?

Question

Я пытаюсь создать систему пакетов / кошельков с разными пользователями.

У меня есть 4 коллекции в mongodb:

Бизнес

const businessSchema = new mongoose.Schema({
  name: { type: String, unique: true },
  .
  .
  .
  packages: [{
    kind: String,
    price: Number,
    numberOfitems: Number
  }]

})

Пользователь

const userSchema = new mongoose.Schema({
  userName: { type: String, unique: true },
  userType: {
    type: String,
    enum: ["USER", "BusinessOwner"],
    default: "USER"
  }
  .
  .
  .
  wallets:[{
    businessID: { type: mongoose.Schema.Types.ObjectId, ref: 'Business'},
    numberOfItems: Number,
    kind: String
  }]

})

покупка

const purchasesSchema = new mongoose.Schema({
  userID: { type: mongoose.Schema.Types.ObjectId, ref: 'User'},
  businessID: { type: mongoose.Schema.Types.ObjectId, ref: 'Business'},
  purchasedPackage:{
    numberOfItems: Number,
    kind: String,
    price: Number
  }

})

Погашенный заказ

const orderSchema = new mongoose.Schema({
  userID: { type: mongoose.Schema.Types.ObjectId, ref: 'User'},
  businessID: { type: mongoose.Schema.Types.ObjectId, ref: 'Business'},
  order:{
    numberOfItems: Number,
    kind: String
  }

})

Поток бизнес-логики выглядит следующим образом:

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

Я изо всех сил пытаюсь найти более простой способ реализации этого рабочего процесса с меньшей избыточностью.

Это моя первая публикация в Stackoverflow, пожалуйста, будьте осторожны со мной:)

Answer 1

По моему мнению, проектирование базы данных на основе документов сильно зависит от того, как приложение представляет данные пользователю, другими словами, какие API доступны. Итак, это зависит от требований системы и пользовательского интерфейса. Поэтому я сделал много предположений во время предложенного дизайна.

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

Требуются 4 коллекции:

1. Пользователь.
2. Business.
3. Пакет.
4. Покупка.

Первый: коллекция пользователей. Используется ТОЛЬКО для хранения информации пользователей, без кошелька.

Второе: бизнес-коллекция Используется ТОЛЬКО для хранения информации о компаниях, не включает пакеты.

В-третьих: Коллекция пакетов Используется для хранения пакетов с денормализованной деловой информацией для лучшего запроса.

const packageSchema = new Schema({
     itemInfo: {}, //The item to be sold in the package: (Name, description, ... etc). Try not to include more than one piece of information in a single field, for example: instead of name being: "ITEM_NAME (The big one)", separate them into two fields: name in one and the size in another. 
     businessInfo: {
        //All data of business needed to show the package in the UI, along with the businessId. 
     },
     count: {}, //Number of items 
     //.... Any other data  needed  for the  package, like price, description, ... etc. 
});

Четвертый: покупка коллекции Коллекция покупок - это представление пользователя, владеющего пакетом.

const purchaseSchema = new Schema({
     user: {}, //Id of the user 
     package: {}, //PackageId along with any denormalized data needed about the package to  display it to the user. 
     status: {type: String, required: true, enum: ["pending", "redeemed", "cancelled"], default: "pending"}, //Status of  the package, for the enum, use a constant variable accessible everywhere in the system, so it's easy to make it consistent.      
});

---

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

• Админы.
  • Добавить новый бизнес:
    • Частота: низкая.
    • Количество вызовов в БД: 1.
    • Простота: Простая вставка вызова в бизнес-коллекции.
  • Изменить существующий бизнес:
    • Частота: очень низкая.
    • Количество вызовов в БД: 3
    • Простота: сложная и неэффективная, требует обновления: бизнес, пакет и коллекции покупок.
• Компании.
  • Добавить новый пакет:
    • Частота: средняя.
    • Количество вызовов в БД: 1.
    • Простота: очень простой, один атомарный вызов вставки в коллекцию Package. (Ненормализованные бизнес-данные могут быть отправлены вместе со звонком, так как вызывающим абонентом является сама компания.
  • Изменить существующий пакет:
    • Частота: низкая.
    • Количество звонков в БД: 1 (поскольку уже купленные предметы не должны меняться).
    • Простота: очень простой, один атомарный вызов обновления для коллекции пакетов.
• Клиенты.
  • Добавить (приобрести) пакет.
    • Частота: очень высокая.
    • Количество вызовов в БД: 1.
    • Простота: очень простой, один атомарный вызов вставки в коллекцию покупок.
  • Погасить пакет.
    • Частота: очень высокая.
    • Количество вызовов в БД: 1.
    • Простота: очень простой, один элементарный вызов обновления для коллекции покупок (Изменение статуса, фильтрация по статусу = "в ожидании" и userId).
  • Получить предметы в кошельке.
    • Частота: очень высокая.
    • Количество обращений в БД: 1.
    • Простота: очень просто, один элементарный вызов для коллекции покупок.
  • Показать, с сортировкой и фильтрацией, все доступные пакеты.
    • Частота: очень высокая.
    • Количество вызовов в БД: 1.
    • Простота: очень просто, один элементарный вызов find для сбора пакетов, все данные там.

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

1. Количество предприятий.
2. Подсчет количества пакетов (активных, неактивных и т. Д.).
3. Общая сумма погашенных денег.
4. Общая сумма денег на бизнес.
5. Средняя сумма денег, выплачиваемая за пользователя.
6. Общая сумма денег, уплаченная за пользователя.

и многое другое.