Правильная структура нового MERN-проекта - PullRequest
0 голосов
/ 23 апреля 2020

Я решил помочь моему другу с сайтом для его новой компании, и я подумал, что сейчас самое время попробовать MERN-стек (mongodb, express, реагировать и node.js).

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

Реляционные данные будут о клиентах и ​​их объектах. Скажем, клиенты, которые регистрируются, и для каждого клиента будет один или несколько автомобилей, которые компания каким-то образом использует.

Это выполнимо в MongoDB? Как бы вы go о его структурировании наилучшим образом? Я имею в виду коллекцию пользователей, имеющую объекты (автомобили) в качестве поля массивов объектов в коллекции пользователей.

Я не делал проект в MERN раньше, и я открыт для любое предложение.

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

Спасибо.

1 Ответ

0 голосов
/ 23 апреля 2020

Чтобы обрабатывать реляционные данные в MongoDB, вам нужно воспользоваться функцией DBrefs.

Я беру этот пример прямо из одного из моих производственных проектов.

Схема сильно урезана, но все еще рассказывает историю функции DBrefs.

Она состоит из двух схем: активность и пользователь

Схема действия здесь:

/*eslint-env node*/

//Dependencies
const mongoose = require('mongoose');

//Global Constant
const Schema = mongoose.Schema;

// Create Schema
const ActivitySchema = new Schema({
    activity: {
        type: String,

    },

    description: {
        type: String,

    },
    intensity: {
        type: String,
    },
    hostId: {
        type: Schema.Types.ObjectId,
        ref: 'user'

    },

}, {
    collection: 'Activity'
});

mongoose.model('activity', ActivitySchema);

Схема пользователя здесь:

/*eslint-env node*/

//Dependencies
const mongoose = require('mongoose');

//Global Constant
const Schema = mongoose.Schema;

//Create Schema
const UserSchema = new Schema({
    name: {
        type: String,

    },
    nickName: {
        type: String

    },
    email: {
        type: String,

    },
    password: {
        type: String,
    },
    profImage: {
        type: String,

    },
    interests: {
        type: Array,

    },

}, {
    collection: 'User'
});

mongoose.model('user', UserSchema);

Как видите, есть поле с именем hostId в конец схемы действия с типом Schema.Types.ObjectId и полем ref:, которое указывает на пользовательскую схему.

По сути, это фактически связывает два документа вместе, сохраняя ObjectId пользователя в коллекции действий (называемой таблицей в SQL).

Эти два документа фактически связаны друг с другом только тогда и только тогда, когда функция запроса, например, .findOne() вызывается вместе с .populate() оператор агрегирования.

Пример:

//Syntax: database.collection.queryFunction

//Normal Query:

db.activity.findOne({activity:'stack overflow event`})

.then(activityData=>{

console.log(activityData);

//You will get something like this:

[
    {
        activity: 'stack overflow event',
        description: 'It's all about SO',
        intensity: 'Very chill',
        hostId: ObjectId(5ea1e3c89dcab6c27d1eb891),
    }
]



})
.catch(err=>console.log(err))


//When you use .populate()

db.activity.findOne({activity:'stack overflow event`})
.populate('user')
.then(activityData=>{

console.log(activityData);

//You will get something like this:

[
    {
        activity: 'stack overflow event',
        description: 'It's all about SO',
        intensity: 'Very chill',
    //The hostId field will get populate with the user object
        hostId: {
            name: 'SO Test User',
            nickName: 'soTest',
            email: 'xxx@xxx.com',
            ....it continues

        }
    }
]


})
.catch(err=>console.log(err))

...