0

Scenario: An entity called 'accessPoint' has an important attribute called 'network'. The application will display some parts of this network attribute, so I decided to store it inside accessPoint documents.

I also decided to store all networks documents (with additional attributes) in a separated collection (for performance reason: it will be used in an autocomplete input in the front end)

accessPoint: {
    id: ObjectId,
    name: String,
    uptime: Number,
    network: {
        subnet: String,
        netmask: Number
    }
}

network: {
    _id: ObjectId
    subnet: String,
    netmask: Number,
    size: Number,
    validatedAt: Date,
    attrX: String,
    attrY: String,
    attrZ: String
}

I have 3 major questions: 1 - Is it a good practice to store networks in a separated colletion? (attention to the requirement above)

2 - Is there any compliance/convention issues building a relationship between these two documents (like an SQL DBMS)?

3 - And, I was wondering... can I store _id as String instead of ObjectId? I've read some advices, but I don't have a conclusive opinion about it. e.g : ... network: { _id: "192.168.1.0/24" } (uniqueness guaranteed :D)

Thanks!

1

Here are some clarifications to your questions:

1 - Is it a good practice to store networks in a separated colletion? (attention to the requirement above)

It depends upon your application functionality and the data.

One of the questions is what is the relationship between the two entities accessPoint and network? Is it One-to-One, One-to_Many or Many-to-Many.

The next question is, what are your significant queries? Which queries are accessed frequently and are important in terms of user experience, performance, etc.

In general, a One-to-One relationship should be modeled as a single document. That is accessPoint and network as one document. Note, each MongoDB document can store up to 16 MB of data.

A One-to-Many relationship can be modeled as a single entity, or as two entities. It is preferred that the related information is stored together - so that it can be accessed together.


2 - Is there any compliance/convention issues building a relationship between these two documents (like an SQL DBMS)?

The reference or relationship relates the two entities, in this case the network related info.

Ideally, it should be the unique field of the network entity. That means, store the neworkentity's _id field (also) in the network sub-document within the accessPoint. This network._id can be used as a reference (or relationship) field.

MongoDB Aggregation Framework allows "join" queries between related collections - the $lookup aggregation stage allows this. So, if you need to access data from both collections as a single query use the $lookup.

Queries accessing a single collection can be formed easily and perform better than the aggregation queries using $lookup.


3 - And, I was wondering... can I store _id as String instead of ObjectId? I've read some advices, but I don't have a conclusive opinion about it. e.g : ... network: { _id: "192.168.1.0/24" } (uniqueness guaranteed :D)

_id field can be of any MongoDB BSON types, except an array field type. Other important things to note about the _id field are:

  • It must be unique (there is a default and an immutable unique index on this field)
  • It must be immutable (this field value cannot be updated or removed for a document).
1

Is it a good practice to store networks in a separated colletion? (attention to the requirement above)

It depends on your app and how do you use them, but I can say collection design is okay.

Is there any compliance/convention issues building a relationship between these two documents (like an SQL DBMS)?

Generally, No-SQL databases don't use for relationship collections.

And, I was wondering... can I store _id as String instead of ObjectId? I've read some advices, but I don't have a conclusive opinion about it. e.g : ... network: { _id: "192.168.1.0/24" } (uniqueness guaranteed :D)

Yes, you can. BTW, uniqueness guaranteed by mongodb. Because _id field has a unique index by default.

db.inspections.insert({ "_id": "192.168.1.0/24", "test": 1 }) 

enter image description here

1
  • Thankss for clarification!! – gugabguerra Oct 27 '20 at 3:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.